Received: from jimi.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa22852; 1 Jun 94 22:38 PDT To: jay@JIMI.CS.UNLV.EDU Subject: bug-chimera may 94 Date: Wed, 01 Jun 1994 22:38:30 -0700 From: Jay Nietling ------- Forwarded Messages Received: from trevnx.BIO.dfo.ca by JIMI.CS.UNLV.EDU id aa23915; 2 May 94 12:24 PDT Received: by trevnx.bio.dfo.ca (NX5.67c/NX3.0M) id AA15424; Mon, 2 May 94 16:24:29 -0300 Date: Mon, 2 May 94 16:24:29 -0300 From: George White 6-8509 Message-Id: <9405021924.AA15424@trevnx.bio.dfo.ca> To: bug-chimera@cs.unlv.edu Subject: chimera dumps core using gopher The problem URL is (chimera 1.49 on a KPC Titan): gopher://ds.internic.net:4320/1netfind This is a netfind gateway. It is erratic. Sometimes searches appear to work. Just now I got a core dump when I attempted a search, then, after restarting chimera I got: $ chimera & [3] 1811 $ Cannot allocate space for element buffer [3]+ Exit 1 after attempting to use the above URL. The third try just producec a core dump. The URL works from Mosaic. Here is a stack trace: dbg_0> trace Reading symbol table from "gopher.o" dbg warning: Can't read symbol table info from file "gopher.o" Reading symbol table from "document.o" dbg warning: Can't read symbol table info from file "document.o" Reading symbol table from "main.o" dbg warning: Can't read symbol table info from file "main.o" "chimera" received a signal 11 SIGSEGV (segmentation violation) `malloc:libc.a Bedford Inst. of Oceanography ------- Message 2 Received: from charles.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa08878; 2 May 94 17:19 PDT To: George White 6-8509 cc: bug-chimera@cs.unlv.edu Subject: Re: chimera dumps core using gopher In-reply-to: Your message of "Mon, 02 May 1994 16:24:29 -0300." <9405021924.AA15424@trevnx.bio.dfo.ca> Date: Mon, 02 May 1994 17:17:37 -0700 From: John Kilburg >The problem URL is (chimera 1.49 on a KPC Titan): >gopher://ds.internic.net:4320/1netfind > >This is a netfind gateway. It is erratic. Sometimes searches >appear to work. Just now I got a core dump when I attempted a >search, then, after restarting chimera I got: Thanks for the report. I am trying it out now. -john ------- Message 3 Received: from nova.gmi.edu by JIMI.CS.UNLV.EDU id aa11080; 2 May 94 18:42 PDT Received: by nova.gmi.edu (4.1/SMI-4.1-DNI) id AA08811; Mon, 2 May 94 21:44:52 EDT Date: Mon, 2 May 1994 21:44:51 -0400 (EDT) From: "R. Stewart Ellis" Subject: Re: chimera dumps core using gopher To: Chimera bug mailing list In-Reply-To: <9405030127.AA08329@nova.gmi.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 2 May 1994, John Kilburg wrote: > >The problem URL is (chimera 1.49 on a KPC Titan): > >gopher://ds.internic.net:4320/1netfind > > > >This is a netfind gateway. It is erratic. Sometimes searches > >appear to work. Just now I got a core dump when I attempted a > >search, then, after restarting chimera I got: > > Thanks for the report. I am trying it out now. > > -john > gopher url's with a port of 4320 are usually go4gw gateways. I have about five on my gopher, 2 dump core and 3 return errors. All work with Mosaic and Lynx (but not doslynx, nothing works with it). The url for the top of the go4gw stuff is: URL: gopher://nova.gmi.edu:70/11/Miscellaneous Network Services Everything in there is go4gw except the x.500 stuff. My gopher is currently not open to the world, but is open to unlv, sun.com, umich.edu. When we get our T1, it will be wide open. Stew ------- Message 4 Received: from igw.merck.com by JIMI.CS.UNLV.EDU id aa16123; 6 May 94 17:27 PDT Received: by igw.merck.com with rsmtp; Fri, 06 May 1994 20:31:59 EDT Date: Fri, 6 May 1994 20:24:37 -0400 From: Anthony Starks To: bug-chimera@cs.unlv.edu Subject: Bad gopher URL chimera 1.49 says: Error Couldn't load document gopher://info.computer.org:70/00/This%20Month%20in%20Computer/Article%20Summaries but Mosaic eats it fine. ------- Message 5 Received: from charles.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa08243; 7 May 94 3:01 PDT To: bug-chimera@charles.CS.UNLV.EDU Subject: Re: Bad gopher URL In-reply-to: Your message of "Fri, 06 May 1994 20:24:37 EDT." Date: Sat, 07 May 1994 03:01:24 -0700 From: John Kilburg >chimera 1.49 says: > >Error > >Couldn't load document > >gopher://info.computer.org:70/00/This%20Month%20in%20Computer/Article%20Summar ies > >but Mosaic eats it fine. I know what the problem is here but I am tired and hungry and I wanna go home. I'll fix it tomorrow. I'll try to release 1.50 this weekend. We've been running it here and it seems to work better and without as many crashes. It has mostly bug fixes...I was going to add some features but they will have to wait (sorry Anthony!). -john ------- Message 6 Received: from charles.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa17033; 7 May 94 19:41 PDT To: bug-chimera@charles.CS.UNLV.EDU Subject: Re: chimera dumps core using gopher In-reply-to: Your message of "Mon, 02 May 1994 21:44:51 EDT." Date: Sat, 07 May 1994 19:41:39 -0700 From: John Kilburg >On Mon, 2 May 1994, John Kilburg wrote: > >> >The problem URL is (chimera 1.49 on a KPC Titan): >> >gopher://ds.internic.net:4320/1netfind >> > >> >This is a netfind gateway. It is erratic. Sometimes searches >> >appear to work. Just now I got a core dump when I attempted a >> >search, then, after restarting chimera I got: >> >> Thanks for the report. I am trying it out now. >> >> -john >> > >gopher url's with a port of 4320 are usually go4gw gateways. I have >about five on my gopher, 2 dump core and 3 return errors. All work with >Mosaic and Lynx (but not doslynx, nothing works with it). > >The url for the top of the go4gw stuff is: > >URL: gopher://nova.gmi.edu:70/11/Miscellaneous Network Services > >Everything in there is go4gw except the x.500 stuff. > >My gopher is currently not open to the world, but is open to unlv, >sun.com, umich.edu. When we get our T1, it will be wide open. > >Stew Is there any documentation on how go4gw servers work? I poked around in the gopher and gopher+ documentation and looked at some FAQs but I couldn't even find a mention of it. -john ------- Message 7 Received: from magic.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa14198; 8 May 94 12:36 PDT To: John Kilburg cc: bug-chimera@charles.cs.unlv.edu Subject: Re: chimera dumps core using gopher In-reply-to: Your message of "Sat, 07 May 1994 19:41:39 PDT." Date: Sun, 08 May 1994 12:36:13 -0700 From: Jenny Zhan >Is there any documentation on how go4gw servers work? I poked around >in the gopher and gopher+ documentation and looked at some FAQs but >I couldn't even find a mention of it. > > -john Search gopherspace using Veronica at NYSERNet. There are some documentation and discussions about go4gw. -Jenny ------- Message 8 Received: from charles.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa05536; 9 May 94 2:49 PDT To: bug-chimera@charles.CS.UNLV.EDU Subject: Announce: Chimera 1.50 Date: Mon, 09 May 1994 02:49:33 -0700 From: John Kilburg I know it is hard to believe but I have just put 1.50 out for anonymous ftp. ftp://ftp.cs.unlv.edu/pub/chimera/chimera-1.50.tar.gz If you folks find it to be reasonable, I will announce it in comp.infosystems.announce. This version mostly contains bug fixes. I've been using it for about a week and it seems much more stable than 1.49. There is some contributed stuff that didn't make it...I apologize for that. The contributed code is usually quite good (better than mine usually) so you can blame it on laziness. Here is a list of things I would like to put in 1.51: 1) proxy server support 2) support for compression encoding 3) .mailcap support I'll probably end up revamping the content file format. I also hope to mess around with the lousy document caching if I have time. Good luck. -john ------- Message 9 Received: from nova.gmi.edu by JIMI.CS.UNLV.EDU id aa14445; 9 May 94 5:13 PDT Received: by nova.gmi.edu (4.1/SMI-4.1-DNI) id AA16765; Mon, 9 May 94 08:16:02 EDT Date: Mon, 9 May 1994 08:16:02 -0400 (EDT) From: "R. Stewart Ellis" Subject: Chimera 1.50 displays source rather than interpreting it. To: Chimera bug mailing list Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Does anyone else have the above problem? SunOS 5.1, gcc 2.3.3, SPARC. R.Stewart(Stew) Ellis, Assoc.Prof., (Off)313-762-9765 ___________________ Humanities & Social Science, GMI Eng.& Mgmt. Inst. / _____ ______ Flint, MI 48504 ellis@nova.gmi.edu / / / / / / Gopher,News and modem consultant, all around hack /________/ / / / / ------- Message 10 Received: from nova.gmi.edu by JIMI.CS.UNLV.EDU id aa19040; 9 May 94 7:48 PDT Received: by nova.gmi.edu (4.1/SMI-4.1-DNI) id AA22615; Mon, 9 May 94 10:50:56 EDT Date: Mon, 9 May 1994 10:50:55 -0400 (EDT) From: "R. Stewart Ellis" Subject: 1.50 can't find giftoppm in /usr/local/bin To: Chimera bug mailing list Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I reported earlier today that 1.50 on my SPARC 1 running Solaris 2.1 will not interpret stuff it fetches from my gopher server. I forgot to mention that this is over term. I have since compiled it on SunOS 4.1.3 and basically everything seems to have gone alright except chimera cannot find giftoppm, which is in /usr/local/bin with mode 755. I edited the content file and put the full path to giftoppm every place it was referenced. Has there been a change in the way paths are handled? I suspect everything else is going to be broken too. Stew ------- Message 11 Received: from nova.gmi.edu by JIMI.CS.UNLV.EDU id aa26328; 9 May 94 9:43 PDT Received: by nova.gmi.edu (4.1/SMI-4.1-DNI) id AA27416; Mon, 9 May 94 12:46:21 EDT Date: Mon, 9 May 1994 12:46:20 -0400 (EDT) From: "R. Stewart Ellis" Subject: Path probs with 1.50 on SunOS 4.1.3 To: Chimera bug mailing list Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I posted earlier about path problems with giftoppm. I now have experienced them with: sh: xbmtopbm: not found sh: mpeg_play: not found I was able to clear up the prob with giftoppm by putting explicit path in content. I have never had this problem before, but that does not seem an optimum solution. Stew ------- Message 12 Received: from charles.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa00864; 9 May 94 11:16 PDT To: bug-chimera@charles.CS.UNLV.EDU Subject: Re: 1.50 can't find giftoppm in /usr/local/bin In-reply-to: Your message of "Mon, 09 May 1994 10:50:55 EDT." Date: Mon, 09 May 1994 11:16:05 -0700 From: John Kilburg >I reported earlier today that 1.50 on my SPARC 1 running Solaris 2.1 will >not interpret stuff it fetches from my gopher server. I forgot to >mention that this is over term. > >I have since compiled it on SunOS 4.1.3 and basically everything seems to >have gone alright except chimera cannot find giftoppm, which is in >/usr/local/bin with mode 755. I edited the content file and put the full >path to giftoppm every place it was referenced. Has there been a change >in the way paths are handled? I suspect everything else is going to be >broken too. > >Stew The problem is that at the top of the default resources file I left my contentPath at the top. Remove that line and everything should work OK. I'll put a new release out. -john ------- Message 13 Received: from igw.merck.com by JIMI.CS.UNLV.EDU id aa01643; 9 May 94 11:34 PDT Received: by igw.merck.com with rsmtp; Mon, 09 May 1994 14:38:59 EDT Date: Mon, 9 May 1994 14:31:45 -0400 From: Anthony Starks To: bug-chimera@cs.unlv.edu Subject: funny business... With 1.50 (and earlier versions as well) if you touch a few sound hyperlinks, after a few, they will not be downloaded A good example of this is the famous M* demo document: http://www.ncsa.uiuc.edu/demoweb/demo.html To reproduce this bug, simply touch each sound hyperlink and then try to repeat. You will see that the previous links will not work. Could this be the caching bugs that John referred to? ------- Message 14 Received: from igw.merck.com by JIMI.CS.UNLV.EDU id aa02380; 9 May 94 11:56 PDT Received: by igw.merck.com with rsmtp; Mon, 09 May 1994 15:00:40 EDT Date: Mon, 9 May 1994 14:52:32 -0400 From: Anthony Starks To: bug-chimera@cs.unlv.edu Subject: more on the sound bite bug The cache(?) bug can be reproduced by going to: http://www.ncsa.uiuc.edu/demoweb/demo.html and touching the first, second, and third sound hyperlink. The first two will work and the third will not. In this state no other hyperlinks that cause an external program to be spawned will work (including the pictures of Smarr and Gore in the same document). ------- Message 15 Received: from nova.gmi.edu by JIMI.CS.UNLV.EDU id aa02608; 9 May 94 12:01 PDT Received: by nova.gmi.edu (4.1/SMI-4.1-DNI) id AA03072; Mon, 9 May 94 15:04:18 EDT Date: Mon, 9 May 1994 15:04:17 -0400 (EDT) From: "R. Stewart Ellis" Subject: Re: 1.50 can't find giftoppm in /usr/local/bin To: John Kilburg Cc: bug-chimera@charles.CS.UNLV.EDU In-Reply-To: <9405091826.AA01469@nova.gmi.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 9 May 1994, John Kilburg wrote: > > > >I have since compiled it on SunOS 4.1.3 and basically everything seems to > >have gone alright except chimera cannot find giftoppm, which is in > >/usr/local/bin with mode 755. I edited the content file and put the full > >path to giftoppm every place it was referenced. Has there been a change > >in the way paths are handled? I suspect everything else is going to be > >broken too. > > > >Stew > > The problem is that at the top of the default resources file > I left my contentPath at the top. Remove that line and everything > should work OK. This indeed fixed the path problems. > > I'll put a new release out. > > -john > Nothing I have tried yet has caused the slightest problem (from SunOS 4.1.3, direct net connection). All the stuff that used to trick chimera, such as mail spool files and go4gw gateways, seems to work perfectly. Stew Ellis ------- Message 16 Received: from trevnx.BIO.dfo.ca by JIMI.CS.UNLV.EDU id aa05907; 9 May 94 12:47 PDT Received: by trevnx.bio.dfo.ca (NX5.67c/NX3.0M) id AA19630; Mon, 9 May 94 16:47:28 -0300 Date: Mon, 9 May 94 16:47:28 -0300 From: George White 6-8509 Message-Id: <9405091947.AA19630@trevnx.bio.dfo.ca> To: bug-chimera@charles.CS.UNLV.EDU Subject: chimera 1.50 Chimera 1.50 has been much more stable than 1.49. This means I haven't needed to test whether bookmarks really do get saved early and often. Now, however, I can look some of those great long ascii documents that come from gopher servers. I find that if I search in such a document, sometimes the scrollbar vanishes and it is hard to get back to the right general area in the file. Since the search highlights the selection, it is not really necesary to put the line with the hit at the top of the screen. For context, it might be better to put the line with the hit near the center of the screen. This would reduce the need to use the scrollbar or to have some idea of the general location in the document. ------- Message 17 Received: from katie.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa07216; 9 May 94 13:01 PDT To: George White 6-8509 cc: bug-chimera@charles.cs.unlv.edu Subject: Re: chimera 1.50 In-reply-to: Your message of "Mon, 09 May 1994 16:47:28 -0300." <9405091947.AA19630@trevnx.bio.dfo.ca> Date: Mon, 09 May 1994 13:00:57 -0700 From: Allen Condit >Chimera 1.50 has been much more stable than 1.49. This means I haven't >needed to test whether bookmarks really do get saved early and often. >Now, however, I can look some of those great long ascii documents that >come from gopher servers. I find that if I search in such a document, >sometimes the scrollbar vanishes and it is hard to get back to the >right general area in the file. Since the search highlights the >selection, it is not really necesary to put the line with the hit at >the top of the screen. For context, it might be better to put the >line with the hit near the center of the screen. This would reduce >the need to use the scrollbar or to have some idea of the general >location in the document. yea, john. i wanted this about 3 months ago when you were testing the search stuff. i believe your response was something like, ``tough!''. (pressure, pressure.... :-) ) allen ------- Message 18 Received: from bionet.BIO.ns.ca by JIMI.CS.UNLV.EDU id aa09082; 9 May 94 13:57 PDT Received: from astra.bio.dfo.ca by BIONET.bio.dfo.ca (PMDF V4.2-11 #3263) id <01HC577JSRDC008X95@BIONET.bio.dfo.ca>; Mon, 9 May 1994 17:54:21 AST Received: by astra.bio.dfo.ca (5.51/5.17) id AA18529; Mon, 9 May 94 17:53:39 ADT Date: Mon, 09 May 1994 17:53:39 -0300 (ADT) From: George White Subject: chimera 1.50 dumps core To: bug-chimera@cs.unlv.edu Message-id: <9405092053.AA18529@astra.bio.dfo.ca> Content-transfer-encoding: 7BIT The problem URL is "http://www.wimsey.com/", and the stack trace gives: dbg_0> trace Reading symbol table from "main.o" dbg warning: Can't read symbol table info from file "main.o" "chimera" received a signal 11 SIGSEGV (segmentation violation) `FindColor:libhtmlw.a Bedford Inst. of Oceanography ------- Message 19 Received: from bdt.com by JIMI.CS.UNLV.EDU id aa16512; 9 May 94 16:56 PDT Received: by bdt.bdt.com (/\==/\ Smail3.1.28.1 #28.3) id ; Mon, 9 May 94 16:51 PDT Message-Id: From: David Beckemeyer Subject: chimera crashes To: bug-chimera@charles.CS.UNLV.EDU Date: Mon, 9 May 1994 16:51:05 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 563 The following URL crashes chimera: http://www.cs.colorado.edu/home/mcbryan/WWWW.html This happened with 1.49 and it still happens with 1.50. I'm running on a Sun4 under SunOS 4.1.3_U1 using stock OpenWindows 3.1. Does anyone else have this configuration? If so, please try the above URL and tell me if it works for you, and if so, what you did differently to build chimera. Thanks. - -- David Beckemeyer (david@bdt.com) | Engineering Services Beckemeyer Development | Hardware/Software Sales P.O. Box 21575, Oakland, CA 94620 | WWW: ------- Message 20 Received: from charles.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa17116; 9 May 94 17:08 PDT To: David Beckemeyer cc: bug-chimera@charles.CS.UNLV.EDU Subject: Re: chimera crashes In-reply-to: Your message of "Mon, 09 May 1994 16:51:05 PDT." Date: Mon, 09 May 1994 17:08:27 -0700 From: John Kilburg >The following URL crashes chimera: > > http://www.cs.colorado.edu/home/mcbryan/WWWW.html > >This happened with 1.49 and it still happens with 1.50. I'm running on >a Sun4 under SunOS 4.1.3_U1 using stock OpenWindows 3.1. Does anyone >else have this configuration? If so, please try the above URL and tell >me if it works for you, and if so, what you did differently to build >chimera. Does it crash when you load the document or does it crash after you submit the document? We talked about this before but I don't remember the answer. -john ------- Message 21 Received: from nova.gmi.edu by JIMI.CS.UNLV.EDU id aa20355; 9 May 94 19:08 PDT Received: by nova.gmi.edu (4.1/SMI-4.1-DNI) id AA16387; Mon, 9 May 94 22:11:10 EDT Date: Mon, 9 May 1994 22:11:10 -0400 (EDT) From: "R. Stewart Ellis" Subject: Success on 1.50, Solaris 2.1 SPARC:perms on content To: Chimera bug mailing list Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I reported earlier today that I was getting source on html links. Even weirder, I discovered that If I reloaded them, I got good-looking WWW pages. I had a few things that were not working at all. Finally I checked the perms on /usr/local/lib/chimera/content: it was 600. It works much better now that it is 644. I have a couple of Urls that will hang the client now, but I have not figured out the parameters yet. In general, all of the gopher stuff works like a charm, plus the www stuff is still working great. I think we are pretty much ready for primetime. Stew Ellis ------- Message 22 Received: from nova.gmi.edu by JIMI.CS.UNLV.EDU id aa20547; 9 May 94 19:16 PDT Received: by nova.gmi.edu (4.1/SMI-4.1-DNI) id AA16620; Mon, 9 May 94 22:19:27 EDT Date: Mon, 9 May 1994 22:19:26 -0400 (EDT) From: "R. Stewart Ellis" Subject: Re: chimera crashes To: David Beckemeyer Cc: bug-chimera@charles.CS.UNLV.EDU In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 9 May 1994, David Beckemeyer wrote: > The following URL crashes chimera: > > http://www.cs.colorado.edu/home/mcbryan/WWWW.html > > This happened with 1.49 and it still happens with 1.50. I'm running on > a Sun4 under SunOS 4.1.3_U1 using stock OpenWindows 3.1. Does anyone > else have this configuration? If so, please try the above URL and tell > me if it works for you, and if so, what you did differently to build > chimera. > > Thanks. > -- > David Beckemeyer (david@bdt.com) | Engineering Services > Beckemeyer Development | Hardware/Software Sales > P.O. Box 21575, Oakland, CA 94620 | WWW: > I just tried this on SunOS 4.1.3, OW3, directly on Internet, and on SunOS 5.1, OW 3.1, connected to Internet through a term socket connection over a modem connection. Both came up without incident. Just another data point. Stew Ellis ------- Message 23 Received: from igw.merck.com by JIMI.CS.UNLV.EDU id aa24193; 9 May 94 21:15 PDT Received: by igw.merck.com with rsmtp; Tue, 10 May 1994 00:20:07 EDT Date: Tue, 10 May 1994 00:12:41 -0400 From: Anthony Starks To: bug-chimera@cs.unlv.edu Subject: 1.50 and the demo document Eariler I reported strange behavior with 1.50 and the M* demo document. It must be a local problem... 1.50 works just fine when compiled on a different machine (Sony News SVR4, X11R5, 12Mb works, Sparc 1, SunOS 4.1.1, X11R4 is flaky) ------- Message 24 Received: from charles.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa24550; 9 May 94 21:26 PDT To: bug-chimera@charles.CS.UNLV.EDU Subject: Re: 1.50 and the demo document In-reply-to: Your message of "Tue, 10 May 1994 00:12:41 EDT." Date: Mon, 09 May 1994 21:26:17 -0700 From: John Kilburg >Eariler I reported strange behavior with 1.50 >and the M* demo document. It must be a local problem... >1.50 works just fine when compiled on a different machine >(Sony News SVR4, X11R5, 12Mb works, Sparc 1, SunOS 4.1.1, X11R4 >is flaky) A bug often manifests itself in different ways on different architectures so there still may be a problem. Makes life interesting. I will investigate it tonight. -john ------- Message 25 Received: from trevnx.BIO.dfo.ca by JIMI.CS.UNLV.EDU id aa06433; 10 May 94 13:49 PDT Received: by trevnx.bio.dfo.ca (NX5.67c/NX3.0M) id AA20395; Tue, 10 May 94 17:49:11 -0300 Date: Tue, 10 May 94 17:49:11 -0300 From: George White 6-8509 Message-Id: <9405102049.AA20395@trevnx.bio.dfo.ca> To: bug-chimera@charles.CS.UNLV.EDU Subject: another problem URL Choosing the "Internet InfoGuide Index button on the following URL: http://www.internic.net/infoguide/forms-index.html gives: 501 Not Implemented We are sorry to be unable to perform the method POST access to area not configured as script area at this time. If you would like to see this capability in future releases, send the method which failed, why you would like to have it, and the server version NCSA/1.1 to httpd@ncsa.uiuc.edu This does work from Mosaic 2.4. - -- George White Bedford Inst. of Oceanography ------- Message 26 Received: from charles.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa11965; 10 May 94 16:23 PDT To: bug-chimera@charles.CS.UNLV.EDU Subject: Re: another problem URL In-reply-to: Your message of "Tue, 10 May 1994 17:49:11 -0300." <9405102049.AA20395@trevnx.bio.dfo.ca> Date: Tue, 10 May 1994 16:23:09 -0700 From: John Kilburg >Choosing the "Internet InfoGuide Index button on the following >URL: > >http://www.internic.net/infoguide/forms-index.html > >gives: > >501 Not Implemented > >We are sorry to be unable to perform the method POST access to area >not configured as script area at this time. > >If you would like to see this capability in future releases, send the >method which failed, why you would like to have it, and the server >version NCSA/1.1 to httpd@ncsa.uiuc.edu > >This does work from Mosaic 2.4. >-- > George White Bedford Inst. of Oceanography This is a strange one. The method is specified as "POST" in the document so I am not sure what the deal is. I'll try to mess around with it tonight. -john ------- Message 27 Received: from charles.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa18906; 10 May 94 20:09 PDT To: bug-chimera@charles.CS.UNLV.EDU Subject: Re: another problem URL In-reply-to: Your message of "Tue, 10 May 1994 17:49:11 -0300." <9405102049.AA20395@trevnx.bio.dfo.ca> Date: Tue, 10 May 1994 20:09:18 -0700 From: John Kilburg >Choosing the "Internet InfoGuide Index button on the following >URL: > >http://www.internic.net/infoguide/forms-index.html > >gives: > >501 Not Implemented >-- > George White Bedford Inst. of Oceanography This was a problem with chimera. It seems to be fixed...I'll release a 1.51 tonight (maybe) which will contain other fixes as well. -john ------- Message 28 Received: from charles.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa21015; 11 May 94 21:19 PDT To: bug-chimera@charles.CS.UNLV.EDU Subject: Chimera 1.51 Date: Wed, 11 May 1994 21:19:04 -0700 From: John Kilburg I have just put Chimera 1.51 out for anonymous ftp. ftp://ftp.cs.unlv.edu/pub/chimera Changes: Removed the 'contentPath' line from Chimera.ad and changed the scrollbar resources slightly. Fixed a problem that caused Chimera to use POST when it shouldn't. Required minor changes in http.c and main.c. Fixed the font definitions in Chimera.ad. Added proxy support for HTTP, Gopher, FTP, and WAIS. Note that WAIS can be proxied but it won't be done natively. -john ------- Message 29 Received: from nova.gmi.edu by JIMI.CS.UNLV.EDU id aa26268; 12 May 94 9:21 PDT Received: by nova.gmi.edu (4.1/SMI-4.1-DNI) id AA08140; Thu, 12 May 94 12:24:03 EDT Date: Thu, 12 May 1994 12:24:02 -0400 (EDT) From: "R. Stewart Ellis" Subject: Inconsistent failure to read certain gopher files To: Chimera bug mailing list Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII If I select the following URL: gopher://nova.gmi.edu:70/hh/Computer%20Policy%20at%20GMI I get the following menu: GMI INFORMATION RESOURCES POLICY: GENERAL CONDITIONS OF USE *Final Draft* GMI INFORMATION RESOURCES POLICIES,ETIQUETTE & RULES Establishment of Computer Policy at GMI General Statement from the Gopher Maintainer IRC at GMI If I attempt to select Estab... I get Error Couldn't load document gopher://nova.gmi.edu:70/00/Computer%20Policy%20at%20GMI/Establishment%20of%20Computer%20Policy%20at%20GMI On General Statement... I get Error Couldn't load document gopher://nova.gmi.edu:70/00/Computer%20Policy%20at%20GMI/General%20Statement%20from%20the%20Gopher%20Maintainer I can read IRC... as well as the 1st two. Here is the directory: # l total 26 drwxrwxr-x 3 root gopher 512 Feb 24 1993 ./ drwxrwxr-x 20 root gopher 1024 May 12 12:09 ../ - -rwxrwxr-x 1 root gopher 321 Jan 4 1993 .cache* drwxrwxr-x 2 root gopher 512 Feb 24 1993 .cap/ - -rwxrwxr-x 1 root gopher 441 Jan 4 1993 Establishment of Computer Policy at GMI* - -rwxrwxr-x 1 gopher gopher 1280 Jan 4 1993 General Statement from the Gopher Maintainer* - -rwxrwxr-x 1 root gopher 553 Jan 4 1993 IRC at GMI* - -rwxrwxr-x 1 root gopher 5482 Feb 25 1993 gmiedu.txt* - -rwxrwxr-x 1 root gopher 11547 Feb 24 1993 policy.draft* I did a chown gopher on General..., it was originally owned by root. I am experiencing similar problems at random with simple text files in other directories. It may have to do with actual filenames over a certain length. My gopher is not open to everyone yet, awaiting a T1 upgrade, Real Soon Now. It is open to nevada.edu, cs.unlv.edu, and umich.edu. Stew Ellis ------- Message 30 Received: from nova.gmi.edu by JIMI.CS.UNLV.EDU id aa28987; 12 May 94 9:59 PDT Received: by nova.gmi.edu (4.1/SMI-4.1-DNI) id AA10045; Thu, 12 May 94 13:02:21 EDT Date: Thu, 12 May 1994 13:02:20 -0400 (EDT) From: "R. Stewart Ellis" Subject: Re: Inconsistent failure to read certain gopher files To: Chimera bug mailing list In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 12 May 1994, R. Stewart Ellis(that's me) wrote: > If I select the following URL: > > gopher://nova.gmi.edu:70/hh/Computer%20Policy%20at%20GMI > > I get the following menu: > > GMI INFORMATION RESOURCES POLICY: GENERAL CONDITIONS OF USE > *Final Draft* GMI INFORMATION RESOURCES POLICIES,ETIQUETTE & RULES > Establishment of Computer Policy at GMI > General Statement from the Gopher Maintainer > IRC at GMI > > If I attempt to select Estab... I get > > Error > > Couldn't load document > > gopher://nova.gmi.edu:70/00/Computer%20Policy%20at%20GMI/Establishment%20of%20Computer%20Policy%20at%20GMI > > > On General Statement... I get > > Error > > Couldn't load document > > gopher://nova.gmi.edu:70/00/Computer%20Policy%20at%20GMI/General%20Statement%20from%20the%20Gopher%20Maintainer > > > I can read IRC... as well as the 1st two. > > Here is the directory: > > # l > total 26 > drwxrwxr-x 3 root gopher 512 Feb 24 1993 ./ > drwxrwxr-x 20 root gopher 1024 May 12 12:09 ../ > -rwxrwxr-x 1 root gopher 321 Jan 4 1993 .cache* > drwxrwxr-x 2 root gopher 512 Feb 24 1993 .cap/ > -rwxrwxr-x 1 root gopher 441 Jan 4 1993 Establishment of Computer Policy at > GMI* > -rwxrwxr-x 1 gopher gopher 1280 Jan 4 1993 General Statement from the Gopher > Maintainer* > -rwxrwxr-x 1 root gopher 553 Jan 4 1993 IRC at GMI* > -rwxrwxr-x 1 root gopher 5482 Feb 25 1993 gmiedu.txt* > -rwxrwxr-x 1 root gopher 11547 Feb 24 1993 policy.draft* > > I did a chown gopher on General..., it was originally owned by root. > > I am experiencing similar problems at random with simple text files in other > directories. It may have to do with actual filenames over a certain length. I just checked one, "GMI Gopher maintainer trades mail with the users", which works with chimera+term 1.50, but does not work with chimera+term 1.51. If I rename it by shortening the name by "the", it also works with 1.51. I have not had time to check the src for anything. > > My gopher is not open to everyone yet, awaiting a T1 upgrade, Real Soon > Now. It is open to nevada.edu, cs.unlv.edu, and umich.edu. > > > Stew Ellis > Stew ------- Message 31 Received: from charles.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa19507; 12 May 94 16:27 PDT To: "Lee A. Butler" cc: bug-chimera@charles.CS.UNLV.EDU Subject: Re: Chimera In-reply-to: Your message of "Thu, 12 May 1994 18:55:10 EDT." <9405121855.aa05260@WOLF.ARL.MIL> Date: Thu, 12 May 1994 16:27:02 -0700 From: John Kilburg For some reason the chimera 1.51 distribution got mangled. I ftp'd it from there myself and installed it at one point so I am not sure what happened. I put a good version out there, please try again. Sorry about that. -john ------- Message 32 Received: from nova.gmi.edu by JIMI.CS.UNLV.EDU id aa29173; 12 May 94 20:08 PDT Received: by nova.gmi.edu (4.1/SMI-4.1-DNI) id AA29243; Thu, 12 May 94 23:11:04 EDT Date: Thu, 12 May 1994 23:11:04 -0400 (EDT) From: "R. Stewart Ellis" Subject: Solution to long filename problem To: Chimera bug mailing list Cc: john@cs.unlv.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I reported earlier today that chimera could not handle some very long filenames on my gopher. I stated that shortening some of them by as few as four characters would make them work right, but that I had not gone chasing in the source. I took the simple expedient of diffing the src dir against the one in 1.50 and found that an array filename[] had been shortened from 256 chars (ridiculous) to 64 (absurd). Although people might point out that I ought to be using .cap files or .name files to assign cool long names rather than using actual cool long names for my files, there are a number of filenames on my gopher that are longer than 64. 128 seemed like a good compromise to me (I was not sure if there would be alignment issues with 80, and 96 is almost 128 anyway). With this value, all the troublesome files seem to work okay now. The diff follows: *** document.c.orig Thu May 12 22:57:16 1994 - --- document.c Thu May 12 22:57:59 1994 *************** *** 201,207 **** int i; Document *d; char hostname[64]; ! char filename[64]; char access[64]; char ext[BUFSIZ]; char shorturl[256]; - --- 201,207 ---- int i; Document *d; char hostname[64]; ! char filename[128]; char access[64]; char ext[BUFSIZ]; char shorturl[256]; I have trouble imagining a hostname more than 64 so I did not change that. Stew Ellis ------- Message 33 Received: from charles.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa29843; 12 May 94 20:33 PDT To: bug-chimera@charles.CS.UNLV.EDU Subject: Re: Solution to long filename problem In-reply-to: Your message of "Thu, 12 May 1994 23:11:04 EDT." Date: Thu, 12 May 1994 20:33:23 -0700 From: John Kilburg >I reported earlier today that chimera could not handle some very long >filenames on my gopher. I stated that shortening some of them by as few as >four characters would make them work right, but that I had not gone chasing >in the source. I took the simple expedient of diffing the src dir against >the one in 1.50 and found that an array filename[] had been shortened from >256 chars (ridiculous) to 64 (absurd). Although people might point out that >I ought to be using .cap files or .name files to assign cool long names >rather than using actual cool long names for my files, there are a number of >filenames on my gopher that are longer than 64. 128 seemed like a good >compromise to me (I was not sure if there would be alignment issues with 80, >and 96 is almost 128 anyway). With this value, all the troublesome files >seem to work okay now. The diff follows: I figured this was the problem. I was messing with ParseURL to fix another problem and was not satisfied with the large size so I made it smaller. Too small apparently. I am going to rewrite the interface to ParseURL for 1.52 to provide for arbritrarily long URLs. I will try to fix the cache, add some HTTP stuff, and add some proxy code. -john ------- Message 34 Received: from manua.gsfc.nasa.gov by JIMI.CS.UNLV.EDU id aa01050; 12 May 94 20:43 PDT Received: by manua.gsfc.nasa.gov (931110.SGI/911001.SGI) for bug-chimera@cs.unlv.edu id AA16413; Thu, 12 May 94 23:45:35 -0400 From: Frank Chen Message-Id: <9405130345.AA16413@manua.gsfc.nasa.gov> Subject: Re: Chimera 1.51 To: John Kilburg Date: Thu, 12 May 1994 23:45:34 -0500 (EDT) Cc: bug-chimera@cs.unlv.edu In-Reply-To: <9405120436.AA17363@manua.gsfc.nasa.gov> from "John Kilburg" at May 11, 94 09:19:04 pm X-Mailer: ELM [version 2.4 PL0] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Length: 629 > > I have just put Chimera 1.51 out for anonymous ftp. > Just installed 1.51 with Xaw3d and found out that the Common.tmpl.dist does not have the support for Xaw3d as in 'config'.(Same for 1.50) I believe that a line 'XAWLIB = XXXAWLIB' at the end should be enough. If I want to access a file thru anonymous ftp on the same machine rather than access thru the 'local mode', what URL should I specify? Both 'lynx'(2.3beta) and 'chimera'(1.50, did not yet test 1.51) won't allow me to do this by using file://manua.gsfc.nasa.gov/pub/frank/frank.html However, XMosaic did go thru anonymous ftp. Any suggestion? Thanks! - -Frank ------- Message 35 Received: from cheviot.ncl.ac.uk by JIMI.CS.UNLV.EDU id aa07247; 13 May 94 0:12 PDT Received: from ncl.blagdon (blagdon.ncl.ac.uk) by cheviot.ncl.ac.uk id (5.65cVUW/NCL-CMA.1.35 for ) with SMTP; Fri, 13 May 1994 08:12:28 +0100 From: Jim Wight Date: Fri, 13 May 94 08:12:12 BST Message-Id: To: bug-chimera@cs.unlv.edu In-Reply-To: <199405130348.AA16503@cheviot.ncl.ac.uk> Subject: Re: Solution to long filename problem Reply-To: J.K.Wight@newcastle.ac.uk > >I took the simple expedient of diffing the src dir against > >the one in 1.50 and found that an array filename[] had been shortened from > >256 chars (ridiculous) to 64 (absurd). Although people might point out that > >I ought to be using .cap files or .name files to assign cool long names > >rather than using actual cool long names for my files, there are a number of > >filenames on my gopher that are longer than 64. 128 seemed like a good > >compromise to me (I was not sure if there would be alignment issues with 80, > >and 96 is almost 128 anyway). With this value, all the troublesome files > >seem to work okay now. The diff follows: > > I figured this was the problem. I was messing with ParseURL to fix > another problem and was not satisfied with the large size so I made it > smaller. Too small apparently. Wouldn't it be better to use MAXPATHLEN from to specify the size of the filename array? Jim ------- Message 36 Received: from charles.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa07551; 13 May 94 0:23 PDT To: bug-chimera@cs.unlv.edu Subject: Re: Solution to long filename problem In-reply-to: Your message of "Fri, 13 May 1994 08:12:12 -0000." Date: Fri, 13 May 1994 00:23:00 -0700 From: John Kilburg >> >I took the simple expedient of diffing the src dir against >> >the one in 1.50 and found that an array filename[] had been shortened from >> >256 chars (ridiculous) to 64 (absurd). Although people might point out tha t >> >I ought to be using .cap files or .name files to assign cool long names >> >rather than using actual cool long names for my files, there are a number o f >> >filenames on my gopher that are longer than 64. 128 seemed like a good >> >compromise to me (I was not sure if there would be alignment issues with 80 , >> >and 96 is almost 128 anyway). With this value, all the troublesome files >> >seem to work okay now. The diff follows: >> >> I figured this was the problem. I was messing with ParseURL to fix >> another problem and was not satisfied with the large size so I made it >> smaller. Too small apparently. > >Wouldn't it be better to use MAXPATHLEN from to specify >the size of the filename array? > >Jim Good point but I think that it won't work in this case because MAXPATHLEN on a gopher/http/ftp/whatever server might be greater than MAXPATHLEN on a client on some other machine. I am going to make it handle arbitrarily long filenames. It should have been able to do this all along, of course. There are all sorts of bizarre constants laying around which need to eliminated. Haven't heard from you in a long time...nice to have you back. -john ------- Message 37 Received: from bionet.BIO.ns.ca by JIMI.CS.UNLV.EDU id aa17031; 13 May 94 4:11 PDT Received: from astra.bio.dfo.ca by BIONET.bio.dfo.ca (PMDF V4.2-11 #3263) id <01HCA7VW7HN4009L1L@BIONET.bio.dfo.ca>; Fri, 13 May 1994 08:07:56 AST Received: by astra.bio.dfo.ca (5.51/5.17) id AA27002; Fri, 13 May 94 08:07:13 ADT Date: Fri, 13 May 1994 08:07:13 -0300 (ADT) From: George White Subject: minor portability issues, size of filename[] To: bug-chimera@cs.unlv.edu Message-id: <9405131107.AA27002@astra.bio.dfo.ca> Content-transfer-encoding: 7BIT This is just a quick list of some minor portability issue for chimera: 1. making sure "NOSTDHDRS" is defined: In Common.tpl, add: MYFLAGS = -DNOSTDHDRS in src/Imakefile, remove: #else MYFLAGS= in libhtmlw/Imakefile, add $(MYFLAGS) to DEFINES = 2. is memmove necessary? ================================= in src/net.c and libhtml/HTMLP.h we find: #define bcopy(src,dst,len) memmove(dst,src,len) memmove() is like memcpy, but allows for source and destination to overlap. memmove() was added in ANSI C, and is not present in BSD and older UNIX versions. I'm not sure that bcopy() can be expected to work with overlapping strings either, and a quick peek at the source suggests that in fact bcopy is not being used with overlapping strings, so a more portable coding would be: in src/net.c and libhtml/HTMLP.h: #define bcopy(src,dst,len) memcpy(dst,src,len) 3. using FILENAME_MAX ====================== R. Stuart Ellis noted a problem in chimera 1.51 with the size of the filename array in src/document.c. The ANSI/ISO standard requires that FILENAME_MAX be defined in . On older unix systems the following idiom can be used if FILENAME_MAX is not defined: #include #ifndef FILENAME_MAX #include #define FILENAME_MAX NAME_MAX #endif I expect that GNU autoconf provides a mechanism to make sure that FILENAME_MAX is defined. - -- ------- Message 38 Received: from netcom11.netcom.com by JIMI.CS.UNLV.EDU id aa05676; 14 May 94 12:09 PDT Received: by netcom.com (8.6.8.1/SMI-4.1/Netcom) id MAA12901; Sat, 14 May 1994 12:09:26 -0700 Date: Sat, 14 May 1994 12:09:26 -0700 From: Thomas Boutell Message-Id: <199405141909.MAA12901@netcom.com> To: bug-chimera@cs.unlv.edu Subject: Chimera home page out of date... The chimera home page says the latest version is 1.49. I've been checking that page for new versions, so I was quietly putting up with problems that have been fixed. I didn't catch on until someone mentioned 1.51 in comp.infosystems.www. Nice new version, though! - -T ------- Message 39 Received: from nova.gmi.edu by JIMI.CS.UNLV.EDU id aa12809; 15 May 94 5:40 PDT Received: by nova.gmi.edu (4.1/SMI-4.1-DNI) id AA22435; Sun, 15 May 94 08:43:12 EDT Date: Sun, 15 May 1994 08:43:11 -0400 (EDT) From: "R. Stewart Ellis" Subject: Trouble with some telnet urls from Yale library gopher To: Chimera bug mailing list Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I found problems with the items above the ^^^^^^^s. They are setting up the telnet hint wrong. The starting url is: gopher://yaleinfo.yale.edu:7000/11/Libraries/by.place/Americas/US/Michigan The source for the page looks like: Gopher directory 1/Libraries/by.place/Americas/US/Michigan on yaleinfo.yale.edu I believe I checked everything, which reveals another problem, chimera did not remember several of the sites. I have not checked the telnet url code, but there may be a problem with the definition of the path variable as regards the gopher info. Stew Ellis ------- Message 40 Received: from tigger.cs.adelaide.edu.au by JIMI.CS.UNLV.EDU id aa17037; 17 May 94 5:28 PDT Received: from zebedee.teaching.cs.adelaide.edu.au (via delivery) by tigger.cs.adelaide.edu.au with SMTP (5.65/UA-5.20) id AA08938; Tue, 17 May 94 21:58:20 +0930 X-Authentic-Sender: jdreynol@zebedee.teaching.cs.adelaide.edu.au Received: by zebedee.teaching.cs.adelaide.edu.au (5.65/SMI-4.1)id AA21671; Tue, 17 May 94 21:58:17 +0930 From: JD REYNOLDS Message-Id: <9405171228.AA21671@zebedee.teaching.cs.adelaide.edu.au> Subject: INstallation problems To: bug-chimera@cs.unlv.edu Date: Tue, 17 May 1994 21:58:16 +0930 (CST) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 734 Dear all Running x11r5, computer science dept. Adelaide University. SunOs. I'm installing within my home directory. Installation goes OK until I type make install whereupen I get this: ... install -c -m 0444 Chimera.ad /usr/local/X11R5/lib/X11/app-defaults/Chimera install: /usr/local/X11R5/lib/X11/app-defaults/Chimera: Read-only file system make[1]: *** [install] Error 1 installing in ./lib... + /bin/sh /usr/local/X11R5/bin/mkdirhier users/cs3/jdreynol/lib ... among the other 25 lines. Does this mean it will never work on this system as it is currently configured? Also, how do I know if it has actually worked, and how do you run it? I'd be heaps grateful for any help. Thanks in advance, JEsse Reynolds. ------- Message 41 Received: from cheviot.ncl.ac.uk by JIMI.CS.UNLV.EDU id aa18426; 17 May 94 7:17 PDT Received: from ncl.blagdon (blagdon.ncl.ac.uk) by cheviot.ncl.ac.uk id (5.65cVUW/NCL-CMA.1.35 for ) with SMTP; Tue, 17 May 1994 15:16:41 +0100 From: Jim Wight Date: Tue, 17 May 94 15:16:14 BST Message-Id: To: bug-chimera@cs.unlv.edu In-Reply-To: <9405171228.AA21671@zebedee.teaching.cs.adelaide.edu.au> Subject: Re: INstallation problems Reply-To: J.K.Wight@newcastle.ac.uk > whereupen I get this: > > ... > install -c -m 0444 Chimera.ad /usr/local/X11R5/lib/X11/app-defaults/Chimera > install: /usr/local/X11R5/lib/X11/app-defaults/Chimera: Read-only file system > make[1]: *** [install] Error 1 > installing in ./lib... > + /bin/sh /usr/local/X11R5/bin/mkdirhier users/cs3/jdreynol/lib > ... > > among the other 25 lines. Does this mean it will never work on this system > as it is currently configured? I suggest you add this line XAPPLOADDIR = the-pathname-of-the-directory-in-which-to-install-Chimera to Common.tmpl. But then you will have to set the environment variable XFILESEARCHPATH to "that-directory/%N" before running chimera. The easiest way is to use a sensible shell that supports functions and write a chimera function e.g. for the shell rc, which I use, fn chimera { XFILESEARCHPATH=that-directory/%N chimera $* } assuming the executable was installed in a directory in the shell's search path. Although I never install applications in the X tree that's not how I solve the problem. Instead I install each application in its own subdirectory in /usr/local with version subdirectories having their own bin/lib/man structure underneath. A symbolic link "current" in the application directory points to the version released to users. That way I can easily install new versions without impinging on the one in use. To release a new version, or reinstate an old one, is as simple as flipping the symbolic link. To simplify access to executables I have a generic script in /usr/local/bin that knows the structure and sets XFILESEARCHPATH to /usr/local/app/current/lib/app-defaults/App before running /usr/local/app/current/bin/app. All I have to do is to link app to the script for each application. That only nedds to be done once as the script is in terms of current, not specific versions. It is usually sufficient, if my memory serves me right, to add these assignments to an Imakefile (or .tmpl file) to achieve installation in other than X's default locations:- APPDIR = /usr/local/app/ BINDIR = ${APPDIR}/bin LIBDIR = ${APPDIR}/lib MANDIR = ${APPDIR}/man/man1 XAPPLOADDIR = ${APPDIR}/lib/app-defaults MKDIRHIER = mkdirhier The last is necessary because some of imake's rules use ${BINDIR}/mkdirhier to create directories that don't exist, but if BINDIR is redefined mkdirhier obviously won't be found in the new place. I am assuming X's bin directory is in the search path. I commend such a scheme to you and suggest that maybe chimera's installation procedure could borrow from it and do beter vis a vis Chimera.ad, if only to suggest setting XAPPLOADDIR. Jim ------- Message 42 Received: from charles.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa23559; 17 May 94 16:12 PDT To: bug-chimera@charles.CS.UNLV.EDU Subject: disk-based cache Date: Tue, 17 May 1994 16:12:52 -0700 From: John Kilburg [Narration: I've was looking through old emails and saw discussions and code about a disk-based cache...] I've been puttering around with a disk-based cache. It seems to work well and since there is a size limit it won't get out of hand and fill your disk (hopefully). The performance seems to be just as good (local filesystem) and chimera uses much less memory. At first I was using a hash function to give unique IDs to use as filenames for the URLs because URLs can't be used as a filename and some URLs are bigger than the max filename size of some machines (this from an earlier discussion here). This worked really well. The problem is that I was using MD5 (the code was handy and is short and easy to incorporate) which results in large (32 character) filenames which are too long for some machines. Now I am messing around with using dbm to keep track of the cache (each document/image has its own file). The reason I tinkering with dbm is that if chimera is killed or dumps core or something then the cache can be recovered when chimera is restarted or at least cleaned up properly. Also, I can now use an integer (makes for short filenames) for a unique ID and just match it up with the URL using the database. If anyone has thoughts on this then please let me know. -john ------- Message 43 Received: from magic-sam.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa24915; 17 May 94 16:37 PDT To: John Kilburg cc: bug-chimera@charles.cs.unlv.edu Subject: Re: disk-based cache In-reply-to: Your message of "Tue, 17 May 1994 16:12:52 PDT." Date: Tue, 17 May 1994 16:37:41 -0700 From: Jay Nietling [Narration: I've was looking through old emails and saw discussions and code about a disk-based cache...] I've been puttering around with a disk-based cache. It seems to work well and since there is a size limit it won't get out of hand and fill your disk (hopefully). The performance seems to be just as good (local filesystem) and chimera uses much less memory. At first I was using a hash function to give unique IDs to use as filenames for the URLs because URLs can't be used as a filename and some URLs are bigger than the max filename size of some machines (this from an earlier discussion here). This worked really well. The problem is that I was using MD5 (the code was handy and is short and easy to incorporate) which results in large (32 character) filenames which are too long for some machines. Now I am messing around with using dbm to keep track of the cache (each document/image has its own file). The reason I tinkering with dbm is that if chimera is killed or dumps core or something then the cache can be recovered when chimera is restarted or at least cleaned up properly. Also, I can now use an integer (makes for short filenames) for a unique ID and just match it up with the URL using the database. If anyone has thoughts on this then please let me know. -john have a look at the berkeley db code. includes hash tables, improved dbm, btrees, etc. of course, if you used it that'd be another thing that you'd have to include or have people find. then the other thing is verifying that the stuff worked on all the machines you wanted chimera to work on. - -jay ------- Message 44 Received: from igw.merck.com by JIMI.CS.UNLV.EDU id aa24965; 17 May 94 16:38 PDT Received: by igw.merck.com with rsmtp; Tue, 17 May 1994 19:42:05 EDT Date: Tue, 17 May 1994 19:34:05 -0400 From: Anthony Starks To: john@charles.CS.UNLV.EDU, bug-chimera@cs.unlv.edu Subject: Re: disk-based cache I don't think chimera should be doing disk caching at all! 1) It makes the program much more complex (MD5 and dbm code, yikes!) 2) It's better to use the caching *servers* like the CERN httpd I suggest that you keep a small fixed size in-core cache. This is clean, simple, and eliminates malloc errors and overhead. The size of the cache can be a compile time constant (say 5-10). ------- Message 45 Received: from igw.merck.com by JIMI.CS.UNLV.EDU id aa01904; 17 May 94 17:57 PDT Received: by igw.merck.com with rsmtp; Tue, 17 May 1994 21:02:15 EDT Date: Tue, 17 May 1994 20:54:40 -0400 From: Anthony Starks To: bug-chimera@cs.unlv.edu Subject: giftoppm badness giftoppm needs to be improved a lot in order to be used with a WWW browser. An alarming number of Web pages come up with the stupid error graphic. Check out: http://siva.cshl.org/cgi-bin/REF52/optimage/spotset/Identified/q http://www.cs.vu.nl/PublicMaintainers/maintainers/dsbouma/test.html Not to mention the need to handle transparency.... ------- Message 46 Received: from katie.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa03711; 17 May 94 18:35 PDT To: Anthony Starks cc: bug-chimera@cs.unlv.edu Subject: Re: giftoppm badness In-reply-to: Your message of "Tue, 17 May 1994 20:54:40 EDT." Date: Tue, 17 May 1994 18:35:36 -0700 From: Allen Condit > >giftoppm needs to be improved a lot in order to be used >with a WWW browser. An alarming number of Web pages come up >with the stupid error graphic. Check out: > >http://siva.cshl.org/cgi-bin/REF52/optimage/spotset/Identified/q >http://www.cs.vu.nl/PublicMaintainers/maintainers/dsbouma/test.html > >Not to mention the need to handle transparency.... don't know about transparency, but with chimera 1.51 and giftoppm of 10dec91, it displays exactly the same thing as Mosaic 2.4 on my color sparc 2 (SunOS 4.1.1 and X11R5). allen ------- Message 47 Received: from citi.umich.edu by JIMI.CS.UNLV.EDU id aa05452; 17 May 94 19:16 PDT Received: from [141.211.170.99] by citi.umich.edu with SMTP; Tue, 17 May 94 22:15:40 -0400 From: Jim.Rees@umich.edu To: John Kilburg Cc: bug-chimera@charles.CS.UNLV.EDU Date: Tue, 17 May 1994 22:15:35 -0400 Subject: Re: disk-based cache Sender: rees@citi.umich.edu In-Reply-To: John Kilburg, Tue, 17 May 1994 16:12:52 PDT I'll agree with Anthony's horror at the idea of bringing in MD5 or dbm for the purpose of on-disk caching. It just isn't that hard. But I'll disagree with his conclusion, and urge you to add the cache. I've been using an on-disk cache with chimera for several months now, and I love it. I implemented it because we're in the mobile computing business here, and sometimes my ip link is a cellular slip line that takes a minute to bring up and costs $1 a minute. Sometimes I don't even have network connectivity. It's pretty cool to be able to bring up chimera even when the network is down! I'm using an extrememly simple url hash, and in three months or so I've never had a collision (well, not one I've noticed, anyway). I would urge against dbm, both because of code complexity, and because of the extra files and I/O required. You'll need to consider the cache validation issue, of course. Right now I just punt and only cache images, which gets it right most of the time. Here's the hash I use: char * urlToCacheName(url) char *url; { static char name[64]; char *cp; int n = 0, wrap; for (cp = url; *cp; cp++) { n ^= *cp; wrap = (n >> 24) & 0xff; n <<= 8; n |= wrap; } sprintf(name, "/usr/local/chimera/icache/chi%x", n); return name; } ------- Message 48 Received: from charles.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa13912; 17 May 94 21:28 PDT To: bug-chimera@charles.CS.UNLV.EDU Subject: Re: disk-based cache In-reply-to: Your message of "Tue, 17 May 1994 22:15:35 EDT." Date: Tue, 17 May 1994 21:28:34 -0700 From: John Kilburg >I'll agree with Anthony's horror at the idea of bringing in MD5 or dbm for >the purpose of on-disk caching. It just isn't that hard. But I'll disagree >with his conclusion, and urge you to add the cache. Actually, it was already working and was not that bad. It wasn't really complex. As it turns out someone has already implemented MD5 and dbm so I did not have to do it. :) I've being using a disk cache version for the last two days and I like it. >I would urge against dbm, both because of code complexity, and because of >the extra files and I/O required. OK. I started using urlToCacheName because it is probably much faster than MD5 (a guess but just take a look at the MD5 code...). -john ------- Message 49 Received: from charles.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa15567; 17 May 94 22:10 PDT To: bug-chimera@charles.CS.UNLV.EDU Subject: more cache stuff Date: Tue, 17 May 1994 22:10:18 -0700 From: John Kilburg OK. Back to a simple cache. I was at this point at about 9pm yesterday. Great. Here are some more things to think about: 1) Should chimera reload old documents? Is the Reload button enough? 2) How big should the cache get? Should there be a "Flush" button instead of having chimera decide when the cache should be cleaned up? The problem is that ALL documents get flushed. 3) I can make chimera present a cache info page without only a little bit of work so that the user can check out the state of the cache. Is this useful? 4) As a part of (3) I can make a list which would allow the user to select a document to flush. Is this useful? Any other ideas? -john ------- Message 50 Received: from igw.merck.com by JIMI.CS.UNLV.EDU id aa18727; 17 May 94 23:14 PDT Received: by igw.merck.com with rsmtp; Wed, 18 May 1994 02:19:42 EDT From: Anthony Starks Subject: Re: more cache stuff To: John Kilburg Date: Wed, 18 May 1994 01:59:33 -0400 (EDT) Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 451 whatever you do make sure the poor user can turn the caching off. I like the idea of a cache info page, but I still favor a small in-core cache; My server caches already and I don't want to deal with any client/server cache conflicts. Anyway, I don't have enough disk space as it is :-( For an interesting article on Web caching see: "A Caching Relay for the World Wide Web" http://www.research.digital.com/SRC/people/Glassman_Steve/paper.html ------- Message 51 Received: from nic.lth.se by JIMI.CS.UNLV.EDU id aa19140; 17 May 94 23:24 PDT Received: from gatekeeper.axis.se by mail.lth.se with smtp (Smail3.1.28.1 #2) id m0q3f3P-000MV9C; Wed, 18 May 94 08:24 MET DST Received: from axisab.axis.se by gatekeeper.axis.se with smtp (Smail3.1.28.1 #20) id m0q3f3M-000trKC; Wed, 18 May 94 08:24 GMT-1:00 Received: by axisab.axis.se (/\==/\ Smail3.1.25.1 #25.7) id ; Wed, 18 May 94 08:21 MET DST Message-Id: To: bug-chimera@cs.unlv.edu Subject: Re: disk-based cache In-reply-to: Your message of "Tue, 17 May 1994 19:34:05 MET DST." Date: Wed, 18 May 1994 08:21:18 MET DST From: Joergen Haegg In message you write: > >I don't think chimera should be doing disk caching at all! No, not if you have a fast link to all servers. But if you don't, it would be very handy. I think it is a good idea. >1) It makes the program much more complex (MD5 and dbm code, yikes!) dbm isn't very high tech. >2) It's better to use the caching *servers* like the CERN httpd The problem is when a lot of clients have the same server, it has to be a *very* fast server. It is better to use the local machine for caching. >I suggest that you keep a small fixed size in-core cache. >This is clean, simple, and eliminates malloc errors and overhead. >The size of the cache can be a compile time constant (say 5-10). One can have both, an example is the in-core dbz for INN (netnews). And if the cache is not on disk, then it would consume too much memory. I think the diskbased cache is a good idea. Especially if you use dbm or BSD db. Why don't make a switch to turn on/off caching? PS. Mosaic has a nice feature, 'f', to get forward to the previous loaded pages after jumping back. ------- Message 52 Received: from cheviot.ncl.ac.uk by JIMI.CS.UNLV.EDU id aa22997; 18 May 94 0:41 PDT Received: from ncl.blagdon (blagdon.ncl.ac.uk) by cheviot.ncl.ac.uk id (5.65cVUW/NCL-CMA.1.35 for ) with SMTP; Wed, 18 May 1994 08:41:21 +0100 From: Jim Wight Date: Wed, 18 May 94 08:41:02 BST Message-Id: To: bug-chimera@cs.unlv.edu In-Reply-To: <199405172324.AA11007@cheviot.ncl.ac.uk> Subject: Re: disk-based cache Reply-To: J.K.Wight@newcastle.ac.uk > Now I am messing around with using dbm to keep track of the cache > (each document/image has its own file). The reason I tinkering with > dbm is that if chimera is killed or dumps core or something then the > cache can be recovered when chimera is restarted or at least cleaned > up properly. Also, I can now use an integer (makes for short filenames) > for a unique ID and just match it up with the URL using the database. How about using the X Context Manager as an alternative to dbm, to which there seems to be some resistance judging from a number of followup messages. I've used it to good effect a number of times to associate data with an id, usually a widget or window id, but it can be anything of type XID (unsigned long). You won't get recovery, but at least there will be no problem about users not having it. It is described in section 16.10 of the R5 "Xlib - C Language Interface" document (I haven't printed R6 yet). Jim ------- Message 53 Received: from trevnx.BIO.dfo.ca by JIMI.CS.UNLV.EDU id aa07319; 18 May 94 4:46 PDT Received: by trevnx.bio.dfo.ca (NX5.67c/NX3.0M) id AA24769; Wed, 18 May 94 08:46:28 -0300 Date: Wed, 18 May 94 08:46:28 -0300 From: George White 6-8509 Message-Id: <9405181146.AA24769@trevnx.bio.dfo.ca> To: bug-chimera@charles.cs.unlv.edu Subject: Re: using dbm to construct a disk-based cache for chimera Now I am messing around with using dbm to keep track of the cache (each document/image has its own file). The reason I tinkering with dbm is that if chimera is killed or dumps core or something then the cache can be recovered when chimera is restarted or at least cleaned up properly. Also, I can now use an integer (makes for short filenames) for a unique ID and just match it up with the URL using the database. If anyone has thoughts on this then please let me know. -john have a look at the berkeley db code. includes hash tables, improved dbm, btrees, etc. of course, if you used it that'd be another thing that you'd have to include or have people find. then the other thing is verifying that the stuff worked on all the machines you wanted chimera to work on. -jay It is not too much to expect a working dbm (or ndbm) -- there are several "free" implementations so there is no excuse for not having it anywhere you have X11. There may be bit of pain sorting out the common reliable subset, but this seems like a very straightforward application so the pain should be minor, especially compared to the alternative (which is to reinvent things that are already handled in dbm). - -- George White Bedford Inst. of Oceanography ------- Message 54 Received: from trevnx.BIO.dfo.ca by JIMI.CS.UNLV.EDU id aa09924; 18 May 94 5:16 PDT Received: by trevnx.bio.dfo.ca (NX5.67c/NX3.0M) id AA24809; Wed, 18 May 94 09:16:44 -0300 Date: Wed, 18 May 94 09:16:44 -0300 From: George White 6-8509 Message-Id: <9405181216.AA24809@trevnx.bio.dfo.ca> To: john@charles.CS.UNLV.EDU Subject: Re: more cache stuff Cc: bug-chimera@charles.CS.UNLV.EDU OK. Back to a simple cache. I was at this point at about 9pm yesterday. Great. Here are some more things to think about: 1) Should chimera reload old documents? Is the Reload button enough? Should be, especially if we can selectively flush documents. 2) How big should the cache get? Should there be a "Flush" button instead of having chimera decide when the cache should be cleaned up? The problem is that ALL documents get flushed. This should be a configurable parameter, probably something that will only be changed infrequently. The default can be a compile time option (which someone who has some experience using a cache can suggest, perhaps with some hints relating to your network status). 3) I can make chimera present a cache info page without only a little bit of work so that the user can check out the state of the cache. Is this useful? Yes. The date/time for the document should be included. Ideally this would take the form of a history tree showing where you have been and indicating by means of a different graphic which items are in the cache. If you can find someone who uses a NeXT, ask them to show you OmniWeb. The place where I need caching are mainly when I have been jumping around and want to go back to something I saw 5 mins. ago. Given a list of URL's, it is easy to produce HTML docs to display the information in various ways. The purpose of a cache is to make it faster to review a document, but caching is only part of the problem of making it easier to retrace your steps. It is also useful to have some navigational aids, and these would give a framework in which to display cache status. This does imply that the database should include things that have been removed from the cache, so you do have to consider a policy to prune the database. 4) As a part of (3) I can make a list which would allow the user to select a document to flush. Is this useful? Also yes, particularly in the developmental period. Any other ideas? Too bad the http protocol doesn't provide a quick way to determine whether a cached document is current (or am I missing something?). I can see some places (e.g., a system used by dozens of students) in which one globally shared cache would be useful, but perhaps this should be done by means of a server and is beyond the scope of chimera (which I see as a tool for small personal systems). - -- George White Bedford Inst. of Oceanography ------- Message 55 Received: from citi.umich.edu by JIMI.CS.UNLV.EDU id aa14666; 18 May 94 7:13 PDT Received: from [141.211.170.99] by citi.umich.edu with SMTP; Wed, 18 May 94 10:12:31 -0400 From: Jim.Rees@umich.edu To: John Kilburg Cc: bug-chimera@charles.CS.UNLV.EDU Date: Wed, 18 May 1994 10:12:27 -0400 Subject: Re: more cache stuff Sender: rees@citi.umich.edu In-Reply-To: John Kilburg, Tue, 17 May 1994 22:10:18 PDT Caching certainly seems to have stirred up some controversy. The size and location of the cache should be configurable, with X resources. It should be possible to disable the cache completely. You need to give some thought to whether you want the cache to be sharable among multiple users. If so, you might want some kind of locking. The http protocol actually defines a header that indicates how long a given object should be cached. I don't remember the name of this header, but it's in the protocol spec. I suggest using this, although as far as I know, none of the servers currently implement it. Finally, let me point out one other benefit of caching, because it has implications for the implementation. My mobile computer is an IBM L40 notebook (stop laughing!). It takes approximately forever for this little machine to convert from gif to pbm. So I've inserted my image cache, not at the document layer, but at the final X image layer. The result is that pages come up instantly, where before they could take a minute or two, even loading documents from the local file system. This adds some complexity, so I won't strongly urge you to do it this way, but just give it some thought. ------- Message 56 Received: from duke.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa25943; 18 May 94 10:49 PDT To: John Kilburg cc: bug-chimera@charles.cs.unlv.edu Subject: Re: more cache stuff In-reply-to: Your message of "Tue, 17 May 1994 22:10:18 PDT." Date: Wed, 18 May 1994 10:49:50 -0700 From: Greg Wohletz >1) Should chimera reload old documents? Is the Reload button enough? >2) How big should the cache get? Should there be a "Flush" button instead > of having chimera decide when the cache should be cleaned up? > The problem is that ALL documents get flushed. My opinion is that the cache should be time driven, the user can set the TTL depending on how much disk space he has. Potentially larger files could have longer TTLs than smaller files, but probably that isn't nessicary. --Greg ------- Message 57 Received: from nova.gmi.edu by JIMI.CS.UNLV.EDU id aa21702; 18 May 94 18:04 PDT Received: by nova.gmi.edu (4.1/SMI-4.1-DNI) id AA03047; Wed, 18 May 94 21:07:31 EDT Date: Wed, 18 May 1994 21:07:31 -0400 (EDT) From: "R. Stewart Ellis" Subject: Re: giftoppm badness To: Chimera bug mailing list In-Reply-To: <9405190051.AB02317@nova.gmi.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 17 May 1994, Allen Condit wrote: > > > >giftoppm needs to be improved a lot in order to be used > >with a WWW browser. An alarming number of Web pages come up > >with the stupid error graphic. Check out: > > > >http://siva.cshl.org/cgi-bin/REF52/optimage/spotset/Identified/q > >http://www.cs.vu.nl/PublicMaintainers/maintainers/dsbouma/test.html > > > >Not to mention the need to handle transparency.... > > don't know about transparency, but with chimera 1.51 and > giftoppm of 10dec91, it displays exactly the same thing > as Mosaic 2.4 on my color sparc 2 (SunOS 4.1.1 and X11R5). > > allen > > I get what seem to be sensible screens from both of these URLs on SunOS 5.1 SPARC, OW3.1, with chimera1.51+term1.14. ------- Message 58 Received: from kauri.vuw.ac.nz by JIMI.CS.UNLV.EDU id aa02954; 19 May 94 17:24 PDT Received: by kauri.vuw.ac.nz id AA11106 (5.65c/IDA-1.4.4 for bug-chimera@cs.unlv.edu); Fri, 20 May 1994 12:24:44 +1200 Date: Fri, 20 May 1994 12:24:44 +1200 From: Nathan Torkington Message-Id: <199405200024.AA11106@kauri.vuw.ac.nz> To: bug-chimera@cs.unlv.edu Subject: http://sunsite.unc.edu/ibic/Writing-CPB.html Open this page with Chimera 1.51 and select o Wilde on Balzac which has URL file://sunsite.unc.edu/pub/electronic-publications/ibic/Commonplace.Book/Wilde_on_Balzac.txt It *immediately* fails (i.e. no network lag). Selecting o Dillard on why we read whose URL is file://sunsite.unc.edu/pub/electronic-publications/ibic/Commonplace.Book/Dillard01 works. Is it the length or the _s? Nat ------- Message 59 Received: from charles.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa03351; 19 May 94 17:34 PDT To: Nathan Torkington cc: bug-chimera@cs.unlv.edu Subject: Re: http://sunsite.unc.edu/ibic/Writing-CPB.html In-reply-to: Your message of "Fri, 20 May 1994 12:24:44 +1200." <199405200024.AA11106@kauri.vuw.ac.nz> Date: Thu, 19 May 1994 17:34:27 -0700 From: John Kilburg >Open this page with Chimera 1.51 and select > o Wilde on Balzac >which has URL >file://sunsite.unc.edu/pub/electronic-publications/ibic/Commonplace.Book/Wilde _on_Balzac.txt >It *immediately* fails (i.e. no network lag). Selecting > o Dillard on why we read >whose URL is >file://sunsite.unc.edu/pub/electronic-publications/ibic/Commonplace.Book/Dilla rd01 >works. Is it the length or the _s? It looks like the length is the problem. This is fixed in 1.52. 1.52 should be available this weekend. -john ------- Message 60 Received: from tigger.cs.adelaide.edu.au by JIMI.CS.UNLV.EDU id aa18582; 19 May 94 23:33 PDT Received: from brian.teaching.cs.adelaide.edu.au (via delivery) by tigger.cs.adelaide.edu.au with SMTP (5.65/UA-5.20) id AA03188; Fri, 20 May 94 16:02:58 +0930 X-Authentic-Sender: jdreynol@brian.teaching.cs.adelaide.edu.au Received: by brian.teaching.cs.adelaide.edu.au (5.65/SMI-4.1)id AA26170; Fri, 20 May 94 16:02:49 +0930 From: JD REYNOLDS Message-Id: <9405200632.AA26170@brian.teaching.cs.adelaide.edu.au> Subject: So are we supposed to panic now? (fwd) To: bug-chimera@cs.unlv.edu Date: Fri, 20 May 1994 16:02:48 +0930 (CST) Cc: rhys@fit.qut.edu.au X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 15168 Forwarded message: From wallach@mcs.com Wed May 18 11:09:26 1994 Message-Id: From: wallach@mcs.com (Harlan Wallach) Subject: So are we supposed to panic now? (fwd) To: otis@cwis.unomaha.edu Date: Tue, 17 May 1994 17:37:59 -0500 (CDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 14820 Forwarded message: >From orion.depaul.edu!RELJC Tue May 17 16:16:17 1994 Message-Id: Date: 17 May 94 15:59:00 CST From: "CARLSON JEFFREY " Subject: So are we supposed to panic now? To: "wallach" cc: "mwallach" From: ORION::WINS%"" 17-MAY-1994 12:27:59.48 To: RELJC CC: Subj: Internet Metering (fwd) Return-Path: Received: from HARVARDA.HARVARD.EDU by orion with SMTP ; Tue, 17 May 94 12:27:14 CST Received: from HARVARDA.HARVARD.EDU by HARVARDA.HARVARD.EDU (IBM VM SMTP V2R2) with BSMTP id 3301; Tue, 17 May 94 13:19:49 EST Received: from HARVARDA.HARVARD.EDU by HARVARDA.HARVARD.EDU (Mailer R2.08 R208004) with BSMTP id 8128; Tue, 17 May 94 13:19:44 EST Date: Tue, 17 May 1994 12:13:21 -0500 Reply-To: Seminar on the Study of Religions Sender: Seminar on the Study of Religions From: alan meyers Subject: Internet Metering (fwd) X-To: online religion seminar To: Multiple recipients of list RELIGION Every list may be receiving multiple copies of this forward, but it seemed important, so here's another. - -- Alan Meyers, Assistant Professor of Religion Lindenwood College, 209 S. Kingshighway, St. Charles, MO 63301 ameyers@lc.lindenwood.edu or txpm33a@prodigy.com - ---------- Forwarded message ---------- Date: Tue, 17 May 94 4:47 +0300 From: MARSHLU@vms.huji.ac.il To: AYN-RAND@IUBVM.BITNET, technology@world.std.com, listening-l@zrz.tu-berlin.de, TheoSci@alpha.augustana.edu, philosophy@world.std.com, castaneda@austin.BSDI.COM, MARKET-L@NERVM.lindenwood.edu, emergence@world.std.com, meta-cybernetics@world.std.com, creativity@world.std.com, meta-discussion@world.std.com, synergetics@world.std.com, auto-philosophy@world.std.com, epistemology@world.std.com, phenomenology@world.std.com, sociology@world.std.com, thoughtpaths@world.std.com, feyerabend@world.std.com, emptiness@world.std.com, phil-books-approval@world.std.com, phil-articles@world.std.com, BRAIN-L@MCGILL1.BITNET Subject: Internet Metering (fwd) Received: by HUJIVMS via SMTP(192.77.173.2) (HUyMail-V6m); Mon, 16 May 94 23:41:56 +0300 Received: from by nysernet.ORG (8.6.7/3.1.090690-NYSERnet Inc.) id QAA09917; Mon, 16 May 1994 16:39:04 -0400 Date: Mon, 16 May 1994 16:39:04 -0400 Message-Id: <16050094232454@HUJIVMS> Reply-To: mochin@nysernet.ORG Originator: mochin@israel.nysernet.org Sender: mochin@nysernet.ORG Precedence: bulk From: "Mark A. Foster" To: Multiple recipients of list Subject: Internet Metering (fwd) X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Forum for discussing the role of intelligence in world transformation - Tikkun Olam The following message was sent to me from another (unaffiliated) list that I subscribe to, and I thought that it was important for people on this list to be aware of it as well. Mark Foster (mfoster@tyrell.net) > It has been a topic of wide discussion in my internet circles for some > time: when would the powers that be start tollgating the internet. It may > be sooner than most believe. I received this message today. The days of > free internet usage seem to be numbered. > > Tom Alexander > > FWD>>ALERT: Internet may be metered in the future. > This should be of wide interest. > > -------------------------------------- > This message is of importance to all of us, since we all > obviously use the internet to a great extent. I received it today, > and am forwarding it "for your information". Thanks > > Subject: Metered Usage of the Internet: JSN > > Please forgive the mass mailing, but I feel this is a subject > which is of great importance to anyone who benefits from the > bountiful resources of the Internet. > > A very bad storm is brooding on the horizon. > > In the future, you might have to pay a charge for every E-mail > message you send or receive, every Usenet article you read, > every kilobyte of data you transfer with ftp, every hypertext > link you follow with NCSA Mosaic or Gopher... > > Hopefully this frightens you as much as it does me. > But it will happen, unless YOU do something about it. > > Please read the attached, fill out the requested info, and > mail it back to mike@essential.org. It also wouldn't hurt to > forward a copy of this to everyone you know on the Internet. > > Thanks for your support. > > Craig Smith, or > Texas A&M University, Dept. of Computer Science > 205 HRBB, 862-2084 (CPSC). [PGP2 Public Key Available on Request] > --- > > TAXPAYER ASSETS PROJECT - INFORMATION POLICY NOTE > May 7, 1994 > > - Request for signatures for a letter to NSF opposing metered > pricing of Internet usage > > - Please repost this request freely > > The letter will be sent to Steve Wolff, the Director of > Networking and Communications for NSF. The purpose of the letter > is to express a number of user concerns about the future of > Internet pricing. NSF recently announced that is awarding five > key contracts to telephone companies to operate four Internet > "Network Access Points" (NAPs), and an NSF funded very high speed > backbone (vBNS). There have been a number of indications that > the telephone companies operating the NAPs will seek permission > from NSF to price NAPs services according to some measure of > Internet usage. The vBNS is expected to act as a testbed for new > Internet pricing and accounting schemes. The letter expresses > the view that metered pricing of Internet usage should be > avoided, and that NSF should ensure that the free flow of > information through Internet listserves and file server sites is > preserved and enhanced. > > Jamie Love, Taxpayer Assets Project (love@essential.org; but > unable to answer mail until May 15). Until then, direct > inquires to Michael Ward. > > If you are willing to sign the letter, send the following > information to Mike Ward of the Taxpayer Assets Project > (mike@essential.org, fax: 202/234-5176; voice: 202/387-8030; > P.O. Box 19367, Washington, DC 20036): > > Names: ___________________________ > Title: ___________________________ (Optional) > Affiliation: ____________________________________ > (for purposes of identification only) > Address: ______________________________________ > City; St, Zip ________________________________ > Email Address: _____________________________________ > Voice: __________________________________ > for verification) > > The letter follows: > > Steve Wolff > Director > Division of Networking and Communications > National Science Foundation > 1800 G Street > Washington, DC 20550 > > Dear Steve: > > It is our understanding that the National Science Foundation > (NSF) and other federal agencies are developing a new > architecture for the Internet that will utilize four new Network > Access Points (NAPs), which have been described as the new > "cloverleaves" for the Internet. You have indicated that NSF is > awarding contracts for four NAPs, which will be operated by > telephone companies (Pac Bell, S.F.; Ameritech, Chicago; Sprint, > NY; and MFS, Washington, DC). We further understand that NSF has > selected MCI to operate its new very high speed backbone (vBNS) > facility. > > There is broad public interest in the outcome of the negotiations > between NSF and the companies that will operate the NAPs and > vBNS. We are writing to ask that NSF consider the following > objectives in its negotiations with these five firms: > > PRICING. > > We are concerned about the future pricing systems for Internet > access and usage. Many users pay fixed rates for Internet > connections, often based upon the bandwidth of the connection, > and do not pay for network usage, such as the transfer of data > using email, ftp, Gopher or Mosaic. It has been widely reported > on certain Internet discussion groups, such as com-priv, that the > operators of the NAPs are contemplating a system of usage based > pricing. > > We are very concerned about any movement toward usage based > pricing on the Internet, and we are particularly concerned about > the future of the Internet Listserves, which allow broad > democratic discourse on a wide range of issues. We believe that > the continued existence and enhancement of the Internet > discussion groups and distribution lists is so important that any > pricing scheme for the NAPs that would endanger or restrict their > use should be rejected by the NSF. > > It is important for NSF to recognize that the Internet is more > than a network for scientific researchers or commercial > transactions. It represents the most important new effort to > expand democracy into a wide range of human endeavors. The open > communication and the free flow of information have make > government and private organizations more accountable, and > allowed citizens to organize and debate the widest range of > matters. Federal policy should be directed at expanding public > access to the Internet, and it should reject efforts to introduce > pricing schemes for Internet usage that would mimic commercial > telephone networks or expensive private network services such as > MCI mail. > > To put this into perspective, NSF officials must consider how any > pricing mechanisms will change the economics of hosting an > Internet electronic mail discussion groups and distribution > lists. Many of these discussion groups and lists are very large, > such as Humanist, GIS-L, CNI-Copyright, PACS-L, CPSR-Announce or > Com-Priv. It is not unusual for a popular Internet discussion > group to have several thousand members, and send out more than > 100,000 email messages per day. These discussion groups and > distribution lists are the backbones of democratic discourse on > the Internet, and it is doubtful that they would survive if > metered pricing of electronic mail is introduced on the Internet. > > Usage based pricing would also introduce a wide range of problems > regarding the use of ftp, gopher and mosaic servers, since it > conceivable that the persons who provide "free" information on > servers would be asked to pay the costs of "sending" data to > persons who request data. This would vastly increase the costs > of operating a server site, and would likely eliminate many > sources of data now "published" for free. > > We are also concerned about the types of accounting mechanisms > which may be developed or deployed to facilitate usage based > pricing schemes., which raise a number of concerns about personal > privacy. Few Internet users are anxious to see a new system of > "surveillance" that will allow the government or private data > vendors to monitor and track individual usage of Information > obtained from Internet listserves or fileserves. > > ANTI-COMPETITIVE PRACTICES > > We are also concerned about the potential for anti- > competitive behavior by the firms that operate the NAPs. Since > 1991 there have been a number of criticisms of ANS pricing > practices, and concerns about issues such as price discrimination > or preferential treatment are likely to become more important as > the firms operating the NAPs become competitors of firms that > must connect to the NAPs. We are particularly concerned about > the announcements by PAC-Bell and Ameritech that they will enter > the retail market for Internet services, since both firms were > selected by NSF to operate NAPs. It is essential that the > contracts signed by NSF include the strongest possible measures > to insure that the operators of the NAPs do not unfairly > discriminate against unaffiliated companies. > > Recommendations: > > As the Internet moves from the realm of the research community to > a more vital part of the nation's information infrastructure, the > NSF must ensure that its decisions reflect the needs and values > of a much larger community. > > 1. The NSF contracts with the NAPs operators will include > clauses that determine how the NAP services will be priced. > It is important that NSF disclose and receive comment on all > pricing proposals before they become final. NSF should > create an online discussion list to facilitate public dialog > on the pricing proposals, and NSF should identify its > criteria for selecting a particular pricing mechanism, > addressing the issue of how the pricing system will impact > the Internet's role in facilitating democratic debate. > > 2. NSF should create a consumer advisory board which would > include a broad cross section of consumer interests, > including independent network service providers (NSPs), > publishers of Internet discussion groups and distribution > lists, academic networks, librarians, citizen groups and > individual users. This advisory board should review a > number of policy questions related to the operation of the > Internet, including questions such as the NAP pricing, NAP > operator disclosure of financial, technical and operational > data, systems of Internet accounting which are being tested > on the vBNS and other topics. > > 3. NSF should solicit public comment, though an online > discussion group, of the types of safeguards against > anticompetitive behavior by the NAPs which should be > addressed in the NSF/NAPs contracts, and on issues such as > NAPs pricing and Internet accounting systems. > > --------------------------------------------------------------------- > TAP-INFO is an Internet Distribution List provided by the Taxpayer > Assets Project (TAP). TAP was founded by Ralph Nader to monitor the > management of government property, including information systems and > data, government funded R&D, spectrum allocation and other government > assets. TAP-INFO reports on TAP activities relating to federal > information policy. tap-info is archived at ftp.cpsr.org; > gopher.cpsr.org and wais.cpsr.org > > Subscription requests to tap-info to listserver@essential.org with > the message: subscribe tap-info your name > --------------------------------------------------------------------- > Taxpayer Assets Project; P.O. Box 19367, Washington, DC 20036 > v. 202/387-8030; f. 202/234-5176; internet: tap@essential.org > --------------------------------------------------------------------- > ------- Message 61 Received: from enst.enst.fr by JIMI.CS.UNLV.EDU id aa16597; 21 May 94 13:35 PDT Received: from ulysse.enst.fr (inf.enst.fr) by enst.enst.fr (4.1/SMI-4.0) id AA17905; Sat, 21 May 94 22:35:00 +0200 Return-Path: Organization: Ecole Nationale Superieure des Telecommunications, Paris Received: from mistral.enst.fr by ulysse.enst.fr (4.1/SMI-4.0) id AA01518; Sat, 21 May 94 22:35:06 +0200 From: Nicolas Pioch Message-Id: <9405212035.AA01518@ulysse.enst.fr> Subject: problems with Chimera-1.51 To: bug-chimera@cs.unlv.edu Date: Sat, 21 May 1994 22:34:59 +0200 (MET DST) X-My-Email: Nicolas.Pioch@enst.fr pioch@fr.net X-Www: http://mistral.enst.fr/~pioch/ X-Face: Need no lame BW 2x2 xface bitmap. Check out the WWW server above. X-Pgp-Key: available, "finger -l pioch@inf.enst.fr" for my public key. X-Nap: Stay away from flying saucers today. X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 891 Hi, I just installed Chimera-1.51 with X11R6 to test out my HTML pages. here are my first problems: 1) I have many files with Le Louvre - Rembrandt (1606-1669) Unlike Mosaic, Chimera doesn't collate the 2 lines of the , and thus only displays the first ("Le Louvre -"). I thought spaces/NL were not significant, are they in the title? 2) http://mistral.enst.fr/~pioch/louvre/paintings/rembrandt/ Chimera doesn't inline the small image of Rembrandt's "Night Watch". It displays the NCSA logo instead. Looking at the server error_log, I can tell that chimera didn't even request the file to the server. This page works fine with Mosaic 2.4 for X11 though... any hint? Thanks for your attention and regards - -- Nicolas PS: I've mailed the -request to be added to the list, in the meantime please Cc: me any followups personally. ------- Message 62 Received: from kauri.vuw.ac.nz by JIMI.CS.UNLV.EDU id aa00668; 21 May 94 20:55 PDT Received: by kauri.vuw.ac.nz id AA01496 (5.65c/IDA-1.4.4 for bug-chimera@cs.unlv.edu); Sun, 22 May 1994 15:55:23 +1200 Date: Sun, 22 May 1994 15:55:23 +1200 From: Nathan Torkington <Nathan.Torkington@vuw.ac.nz> Message-Id: <199405220355.AA01496@kauri.vuw.ac.nz> To: bug-chimera@cs.unlv.edu Subject: Not really a bug I just changed chimera's requesters (the dialog boxes with text entry fields) to delete selected text when backspace is pressed, or just delete normally if there is no selection. This brings it in line with Motif and Windows' look'n'feel. The patch is really simple, and follows this mail message. The reason I post this to the bug list is that it was bugging me ;-). To apply it, save the bit after --cut-here-- into a file, move into the chimera-1.51 directory and type patch -p0 < patchfile Cheers; Nat - --cut-here-- *** src/requester.c Wed Feb 23 19:03:41 1994 - --- gnat-src/requester.c Sun May 22 10:04:44 1994 *************** *** 69,74 **** - --- 69,92 ---- } /* + * bs-func + * Called when the user pressed backspace + */ + static void + BSFunc(Widget w, XEvent *event, String *params, Cardinal *num_params) + { + XawTextPosition begin, end; + + XawTextGetSelectionPos(w, &begin, &end); + if (begin == end) { + /* no selection, do a normal backspace */ + XtCallActionProc(w, "delete-previous-character", event, params, *num_params); + } else { + XtCallActionProc(w, "kill-selection", event, params, *num_params); + } + } + + /* * CreateRequester * */ *************** *** 89,95 **** int rx, ry, wx, wy; unsigned int mask; int dwidth, dheight; ! XtActionsRec action_rec[1]; static RequesterCallbackData d; if (requester) - --- 107,113 ---- int rx, ry, wx, wy; unsigned int mask; int dwidth, dheight; ! XtActionsRec action_rec[2]; static RequesterCallbackData d; if (requester) *************** *** 138,145 **** action_rec[0].proc = (XtActionProc)OKFunc; action_rec[0].string = "ok-func"; XtAppAddActions(XtWidgetToApplicationContext(flist[i].w), ! action_rec, 1); XtOverrideTranslations(flist[i].w, XtParseTranslationTable( - --- 156,165 ---- action_rec[0].proc = (XtActionProc)OKFunc; action_rec[0].string = "ok-func"; + action_rec[1].proc = (XtActionProc)BSFunc; + action_rec[1].string = "bs-func"; XtAppAddActions(XtWidgetToApplicationContext(flist[i].w), ! action_rec, 2); XtOverrideTranslations(flist[i].w, XtParseTranslationTable( *************** *** 146,152 **** "Ctrl<Key>M: ok-func()\n\ Ctrl<Key>J: ok-func()\n\ <Key>Linefeed: ok-func()\n\ ! <Key>Return: ok-func()")); } box = XtCreateManagedWidget("requesterbox", - --- 166,173 ---- "Ctrl<Key>M: ok-func()\n\ Ctrl<Key>J: ok-func()\n\ <Key>Linefeed: ok-func()\n\ ! <Key>Return: ok-func()\n\ ! <Key>Delete: bs-func()\n")); } box = XtCreateManagedWidget("requesterbox", ------- Message 63 Received: from charles.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa27080; 23 May 94 2:22 PDT To: bug-chimera@charles.CS.UNLV.EDU Subject: 1.52 Date: Mon, 23 May 1994 02:22:13 -0700 From: John Kilburg <john@charles.CS.UNLV.EDU> I put 1.52 out tonight. ftp://ftp.cs.unlv.edu/pub/chimera/chimera-1.52.tar.gz This version has a disk-based cache (in case you had not heard :) so watch out during the installation. By default, the cache size is 4000000 bytes, uses ~/chimera_cache for the cache directory, and expires documents after 4 hours. Environment variables: CHIMERA_DOC_TTL - if 0 then documents are not expired. CHIMERA_CACHE - specifies cache directory. CHIMERA_CACHE_OFF - existence turns off cache CHIMERA_CACHE_SIZE - specifies max cache size. 0 means no limit. This may or may not be documented in INSTALL very well. I will also document this in the help page. I know that is very lazy but I figured the new cache is so much better that it won't hurt for now. Besides you might all decide it sucks and convince me to change it. Corresponding X resources will appear in 1.53. I've had good luck surfing the net over the past few days. It seems to be a lot more reliable and it performs reasonably. Nearly every http, gopher, ftp, and file URL that I've seen works fine. Caching of images needs to improve; they are cached as GIF not as PPM/PGM/PBM. I'm working on a way to make it cache the portable versions without mangling the code. Delayed image loading needs to be added (code was contributed but there were more important problems, I think) and an interrupt button needs to be added (also contributed). There was also a patch to make the text widgets more functional which will probably get in the next release. I tested chimera a bit without the cache. It seems to work fine so folks with proxy servers or a lot of time on their hands should be happy. The code managed to stay about the same size throughout all of this which is a nice bonus. I think it ended up being simpler as well. The comments about caching and other things were EXTREMELY HELPFUL (not that they got through my thick skull). I have a fairly large database of chimera emails that I mull over when in doubt. If you have any thoughts, please let the list know. Thanks. -john ------- Message 64 Received: from igw.merck.com by JIMI.CS.UNLV.EDU id aa20570; 23 May 94 12:17 PDT Received: by igw.merck.com with rsmtp; Mon, 23 May 1994 15:15:38 EDT Date: Mon, 23 May 1994 14:54:04 -0400 From: Anthony Starks <anthony_starks@merck.com> To: bug-chimera@cs.unlv.edu Subject: chimera save as mail hack 132,137d131 < * command for mailing -- ajs < */ < < #define MAILCMD "/usr/lib/sendmail %s" < < /* 883,884d876 < char cmdline[256]; < char *mp; /* buffer and pointer for mail hack-- ajs */ 957,967c949 < /* hack to mail instead of save to disk -- ajs */ < < if ((mp = strchr(s, '@')) != NULL) < { < sprintf(cmdline, MAILCMD, s); < fp = popen(cmdline, "w"); < } < else < fp = fopen(s, "w"); < < - --- > fp = fopen(s, "w"); 975,981d956 < < /* add the URL as the subject line if mailing -- ajs */ < < if (mp) < fprintf(fp, "Subject: %s\n\n", r->dlist->url); < < 983,986c958 < if (mp) < pclose(fp); < else < fclose(fp); - --- > fclose(fp); 1539c1511 < flist[0].prompt = "Enter a filename or email address for the document"; - --- > flist[0].prompt = "Enter a filename for the document"; ------- Message 65 Received: from citi.umich.edu by JIMI.CS.UNLV.EDU id aa22116; 23 May 94 12:42 PDT Received: from [141.211.128.188] by citi.umich.edu with SMTP; Mon, 23 May 94 15:41:02 -0400 From: Jim.Rees@umich.edu To: bug-chimera@cs.unlv.edu Date: Mon, 23 May 1994 15:41:01 -0400 Subject: Re: chimera save as mail hack Sender: rees@citi.umich.edu In-Reply-To: Anthony Starks, Mon, 23 May 1994 14:54:04 EDT Amusing. If this were to become a standard feature, I would hope the mailer command would be configurable. ------- Message 66 Received: from igw.merck.com by JIMI.CS.UNLV.EDU id aa29418; 23 May 94 15:28 PDT Received: by igw.merck.com with rsmtp; Mon, 23 May 1994 18:33:45 EDT Date: Mon, 23 May 1994 18:19:54 -0400 From: Anthony Starks <anthony_starks@merck.com> To: bug-chimera@cs.unlv.edu Subject: Re: save as mail hack I forgot to mention that the save as mail diffs are for main.c ------- Message 67 Received: from igw.merck.com by JIMI.CS.UNLV.EDU id aa29427; 23 May 94 15:29 PDT Received: by igw.merck.com with rsmtp; Mon, 23 May 1994 18:33:46 EDT Date: Mon, 23 May 1994 18:20:27 -0400 From: Anthony Starks <anthony_starks@merck.com> To: bug-chimera@cs.unlv.edu Subject: reload on resize? how come 1.52 reloads the whole page upon resize? ------- Message 68 Received: from nic.lth.se by JIMI.CS.UNLV.EDU id aa17450; 24 May 94 0:43 PDT Received: from gatekeeper.axis.se by mail.lth.se with smtp (Smail3.1.28.1 #2) id m0q5r8j-000MUlC; Tue, 24 May 94 09:43 MET DST Received: from axisab.axis.se by gatekeeper.axis.se with smtp (Smail3.1.28.1 #20) id m0q5r8h-000tmvC; Tue, 24 May 94 09:42 GMT-1:00 Received: by axisab.axis.se (/\==/\ Smail3.1.25.1 #25.7) id <m0q5r6C-000pesC@axisab.axis.se>; Tue, 24 May 94 09:40 MET DST Message-Id: <m0q5r6C-000pesC@axisab.axis.se> To: bug-chimera@cs.unlv.edu Subject: Re: Not really a bug In-reply-to: Your message of "Sun, 22 May 1994 15:55:23 MET DST." <199405220355.AA01496@kauri.vuw.ac.nz> Date: Tue, 24 May 1994 09:40:10 MET DST From: Joergen Haegg <jh@axis.se> In message <199405220355.AA01496@kauri.vuw.ac.nz>you write: > >I just changed chimera's requesters (the dialog boxes with text entry >fields) to delete selected text when backspace is pressed, or just >delete normally if there is no selection. This brings it in line with >Motif and Windows' look'n'feel. Should be configurable for those who don't like the Motif-way (like me :-). (compile-option?) ------- Message 69 Received: from cheviot.ncl.ac.uk by JIMI.CS.UNLV.EDU id aa18588; 24 May 94 1:27 PDT Received: from ncl.blagdon (blagdon.ncl.ac.uk) by cheviot.ncl.ac.uk id <AA17993@cheviot.ncl.ac.uk> (5.65cVUW/NCL-CMA.1.35 for <bug-chimera@cs.unlv.edu>) with SMTP; Tue, 24 May 1994 09:27:29 +0100 From: Jim Wight <J.K.Wight@newcastle.ac.uk> Date: Tue, 24 May 94 09:27:13 BST Message-Id: <AA27665.9405240827.blagdon@uk.ac.newcastle> To: bug-chimera@cs.unlv.edu In-Reply-To: <m0q5r6C-000pesC@axisab.axis.se> Subject: Re: Not really a bug Reply-To: J.K.Wight@newcastle.ac.uk Joergen Haegg writes: > > In message <199405220355.AA01496@kauri.vuw.ac.nz>you write: > > > >I just changed chimera's requesters (the dialog boxes with text entry > >fields) to delete selected text when backspace is pressed, or just > >delete normally if there is no selection. This brings it in line with > >Motif and Windows' look'n'feel. > > Should be configurable for those who don't like the Motif-way (like me :-). > (compile-option?) It should most definitely not be a compile option. The builder of chimera is not necessarily the sole user of the executable, and therefore other potential users should be catered for. Make it configurable at run time, probably by writing a new action that can be bound to <Key>BackSpace. Jim ------- Message 70 Received: from ldgo.columbia.edu by JIMI.CS.UNLV.EDU id aa28755; 24 May 94 6:32 PDT Received: from rainbow.ldgo.columbia.edu by lamont.ldgo.columbia.edu (4.1/SMI-3.2) id AA28874; Tue, 24 May 94 09:32:43 EDT Received: by rainbow.ldgo.columbia.edu (931110.SGI/890607.SGI) (for @lamont.ldgo.columbia.edu:bug-chimera@charles.CS.UNLV.EDU) id AA19426; Tue, 24 May 94 09:32:53 -0400 Date: Tue, 24 May 94 09:32:53 -0400 From: Benno Blumenthal <benno@rainbow.ldgo.columbia.edu> Message-Id: <9405241332.AA19426@rainbow.ldgo.columbia.edu> To: bug-chimera@charles.CS.UNLV.EDU Subject: local files with Chimera 1.52 Hello, I just tried out chimera 1.52 with my rather old linux system. I cannot read local files (it core dumps or says document is not accessible). chimera file:/our/benno/public_html/benno.html core dumps chimera benno.html says error: couldn't load document. http documents work fine; 1.50 was fine, too. - -- -- Benno Benno Blumenthal Lamont-Doherty Earth Observatory of Columbia University Palisades NY 10964 (914) 365-8350 internet: benno@lamont.ldeo.columbia.edu ------- Message 71 Received: from terra.oscs.montana.edu by JIMI.CS.UNLV.EDU id aa03312; 24 May 94 8:59 PDT Received: from runestone.lib.montana.edu by terra.oscs.montana.edu (5.65/Ultrix3.0-C) id AA22218; Tue, 24 May 1994 09:59:00 -0600 Message-Id: <9405241559.AA22218@terra.oscs.montana.edu> X-Sender: greenman@terra.oscs.montana.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 24 May 1994 10:03:25 -0600 To: bug-chimera@cs.unlv.edu From: Bruce Albert <aliba@trex.oscs.montana.edu> Subject: Can't ftp chimera X-Mailer: <PC Eudora Version 1.4> When I try to connect to your ftp server, I get a message about not accepting connections from "improperly configured name servers". Since I have no control over how the name server here is configured, would you please tell me where I can obtain this software successfully. Thank You. Dr. Bruce Albert aliba@msu.oscs.montana.edu ------- Message 72 Received: from charles.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa24223; 24 May 94 17:05 PDT To: Bruce Albert <aliba@trex.oscs.montana.edu> cc: bug-chimera@cs.unlv.edu Subject: Re: Can't ftp chimera In-reply-to: Your message of "Tue, 24 May 1994 10:03:25 MDT." <9405241559.AA22218@terra.oscs.montana.edu> Date: Tue, 24 May 1994 17:05:53 -0700 From: John Kilburg <john@charles.CS.UNLV.EDU> >When I try to connect to your ftp server, I get a message about not >accepting connections from "improperly configured name servers". Since I >have no control over how the name server here is configured, would you >please tell me where I can obtain this software successfully. Thank You. > >Dr. Bruce Albert >aliba@msu.oscs.montana.edu Try ftp'ing it from sunsite.unc.edu. The directory is /pub/packages/infosystems/WWW/Chimera -john ------- Message 73 Received: from charles.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa24355; 24 May 94 17:09 PDT To: Benno Blumenthal <benno@rainbow.ldgo.columbia.edu> cc: bug-chimera@charles.CS.UNLV.EDU Subject: Re: local files with Chimera 1.52 In-reply-to: Your message of "Tue, 24 May 1994 09:32:53 EDT." <9405241332.AA19426@rainbow.ldgo.columbia.edu> Date: Tue, 24 May 1994 17:09:00 -0700 From: John Kilburg <john@charles.CS.UNLV.EDU> >I just tried out chimera 1.52 with my rather old linux system. I >cannot read local files (it core dumps or says document is not >accessible). > > chimera file:/our/benno/public_html/benno.html > >core dumps > > chimera benno.html > >says error: couldn't load document. http documents work fine; 1.50 >was fine, too. I haven't been able to reproduce this. Can you give me a listing from 'where' in gdb? -john ------- Message 74 Received: from charles.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa24618; 24 May 94 17:14 PDT To: bug-chimera@cs.unlv.edu Subject: Re: reload on resize? In-reply-to: Your message of "Mon, 23 May 1994 18:20:27 EDT." Date: Tue, 24 May 1994 17:14:46 -0700 From: John Kilburg <john@charles.CS.UNLV.EDU> >how come 1.52 reloads the whole page upon resize? As far as I can tell it doesn't. Do you have an example URL? -john ------- Message 75 Received: from wavelet.apl.washington.edu by JIMI.CS.UNLV.EDU id aa08106; 24 May 94 22:13 PDT Received: by wavelet.apl.washington.edu (5.65c) id AA21159; Tue, 24 May 1994 22:12:58 -0700 From: Mike Kenney <mike@wavelet.apl.washington.edu> Message-Id: <199405250512.AA21159@wavelet.apl.washington.edu> Subject: memory bug in v1.52 To: bug-chimera@cs.unlv.edu Date: Tue, 24 May 1994 22:12:57 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 976 System: i486 Linux 1.0.6 Problem: Segmentation fault when loading a local HTML file. It occurs in 'DestroyURLParts' when freeing 'up->hostname'. The pointer is non-zero but does not point to allocated memory. Here's the quick fix I applied, it just insures that all elements of an allocated structure will be initialized to zero. - ----------------------------------------------------------------------- *** util.c.orig Tue May 24 21:48:33 1994 - --- util.c Tue May 24 21:50:21 1994 *************** *** 38,43 **** - --- 38,44 ---- #endif #include <ctype.h> + #include <memory.h> #include "util.h" *************** *** 69,74 **** - --- 70,78 ---- { OutOfMemory(); } + + /* Zero it out ... */ + memset(s, 0, len); return(s); } - ----------------------------------------------------------------------- BTW, 'chimera' is a *great* program. - -- Mike Kenney UW Applied Physics Lab mikek@apl.washington.edu ------- Message 76 Received: from charles.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa12391; 25 May 94 0:03 PDT To: Mike Kenney <mike@wavelet.apl.washington.edu> cc: bug-chimera@cs.unlv.edu Subject: Re: memory bug in v1.52 In-reply-to: Your message of "Tue, 24 May 1994 22:12:57 PDT." <199405250512.AA21159@wavelet.apl.washington.edu> Date: Wed, 25 May 1994 00:03:15 -0700 From: John Kilburg <john@charles.CS.UNLV.EDU> >System: i486 Linux 1.0.6 > >Problem: Segmentation fault when loading a local HTML file. It > occurs in 'DestroyURLParts' when freeing 'up->hostname'. > The pointer is non-zero but does not point to allocated > memory. Thanks. I did not use your patch...I fixed MakeURLParts. -john ------- Message 77 Received: from mail.unet.umn.edu by JIMI.CS.UNLV.EDU id aa00760; 25 May 94 7:12 PDT Received: from umnstat.stat.umn.edu (otter.stat.umn.edu) by mail.unet.umn.edu (5.65c) id AA03685; Wed, 25 May 1994 09:12:05 -0500 Date: Wed, 25 May 1994 09:12:03 -0500 From: "Bret J. Musser" <bjm@umnstat.stat.umn.edu> Message-Id: <199405251412.AA08269@umnstat.stat.umn.edu> Received: by umnstat.stat.umn.edu; Wed, 25 May 1994 09:12:03 -0500 To: bug-chimera@cs.unlv.edu Subject: Bugs in loading html document (1.52) Hello, I downloaded chimera version 1.52 and have encountered a few problems with it. 1) When loading HTML documents, they are sometimes first displayed in source form, not formatted. 2) Chimera refuses to display some in-line images, but this depends on the screen Chimera is displaying to. Running over MacX to a color Macintosh, I can see images, but sitting at the console of a color DECstation 5000 I cannot. I compiled Chimera on a DECstation 5000 running Ultrix 4.2 and using gcc. I used the Xaw3d library. Thanks in advance for any pointers, Bret Musser bjm@stat.umn.edu http://stat.umn.edu/~bjm (which contains the images and HTML that Chimera isn't loading properly) ------- Message 78 Received: from capitoglio.enserb.u-bordeaux.fr by JIMI.CS.UNLV.EDU id aa02809; 25 May 94 8:22 PDT Received: from didon.enserb.u-bordeaux.fr by capitoglio (4.1/SM-mailhost-BORDEAUX-1.0) id AA23437; Wed, 25 May 94 17:17:18 +0200 Received: by didon.enserb.u-bordeaux.fr (5.0/SM-BORDEAUX0.1) id AA10607; Wed, 25 May 1994 17:21:29 --100 Message-Id: <9405251521.AA10607@didon.enserb.u-bordeaux.fr> Subject: bug in forms To: chimera <bug-chimera@cs.unlv.edu> Date: Wed, 25 May 1994 17:21:27 +0200 (MET DST) From: stampf@enserb.u-bordeaux.fr Reply-To: stampf@enserb.u-bordeaux.fr Return-Path: <stampf@ENSERB.U-Bordeaux.FR> Organization: ENSERB - Universite Bordeaux I - France X-Face: f8`H!qN.1&nHJiX2Mq_ay[;qAu1Wwu`vTg|sd!.2-_K>~MDE"#xlBy?/D)OJjz.9g?vIp)" y*:y}5QB\1;'hwr6HzGur8\iCg1iC9L"pra/R^:Gm=K*_>dbeD@+\1RS X-Www: http://esquilino.enserb.u-bordeaux.fr:8001/~stampf/index.html X-Pgp: finger -l stampf@capitoglio.enserb.u-bordeaux.fr X-Advert: Join undernet : /server fr.undernet.org 7000 (IRC) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1223 Hello ! When I have a <form> </form> with just one field, when I press enter, the form isn't sent to the host, Chimera will just "beep". In Mosaic, it send the form... And since I decided to use chimera that's because we experienced a problem with it, but never had any answer... Another problem : I can't usually get an error message "Unknown method GET" for some forms. Any hints ? thanks in advance, - -- ## +----------------------+ +----#--,-. +---------------------------+ | |\ /| _ . | _ _ | / # / ^ \ |Nicolas Stampf | | | \/ | (_| | | (= | | | | | |stampf@enserb.u-bordeaux.fr| +-+--------------------+ + ---...+---+ +-------------------------+-+ | ||| | | Computer Science School ||| Bordeaux FRANCE | +---------------------------------------------------------------+ Watch out chombatta IRC can fry your brain as fast as your last cyberconsole Yep. That's life <a href="http://esquilino.enserb.u-bordeaux.fr:8001/~stampf/index.html">hit</a> ------- Message 79 Received: from gw.home.vix.com by JIMI.CS.UNLV.EDU id aa02651; 25 May 94 17:47 PDT Received: by gw.home.vix.com id AA20554; Wed, 25 May 94 17:47:28 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by office; id AA03239; Wed, 25 May 94 17:47:26 -0700 Date: Wed, 25 May 94 17:47:26 -0700 From: paul@vix.com Message-Id: <9405260047.AA03239@office> To: bug-chimera@cs.unlv.edu Subject: bugs in chimera 1.52 1. clicking "source" over and over causes the displayed text to change (grow). 2. "make install" created /app-defaults and /app-defaults/Chimera rather than /usr/X11/lib/X11/app-defaults/Chimera. 3. a lot of library functions are used without any "extern"'ing, so the compile complains about quite a few implicit function definitions. ------- Message 80 Received: from wolf.arl.mil by JIMI.CS.UNLV.EDU id aa15849; 25 May 94 22:29 PDT Date: Thu, 26 May 94 1:24:39 EDT From: "Lee A. Butler" <butler@arl.mil> To: bug-chimera@cs.unlv.edu Subject: Bug in 1.51 resources files Message-ID: <9405260124.aa04127@wolf.arl.mil> The Chimera.ad file that comes with 1.51 lists the following: *urldisplay.displayCaret: true *urldisplay.editType: read *titledisplay.displayCaret: False *titledisplay.editType: read Since these are actually resources of the "text" widget, they should probably be listed as: *urldisplay*displayCaret: true *urldisplay*editType: read *titledisplay*displayCaret: False *titledisplay*editType: read Lee A. Butler Attn: AMSRL-SL-BV U.S. Army Research Laboratory Internet: butler@brl.mil Aberdeen Proving Ground, MD 21005-5068 Phone: (410) 278-9200 ------- Message 81 Received: from charles.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa16017; 25 May 94 22:34 PDT To: "Lee A. Butler" <butler@arl.mil> cc: bug-chimera@cs.unlv.edu Subject: Re: Bug in 1.51 resources files In-reply-to: Your message of "Thu, 26 May 1994 01:24:39 EDT." <9405260124.aa04127@wolf.arl.mil> Date: Wed, 25 May 1994 22:34:12 -0700 From: John Kilburg <john@charles.CS.UNLV.EDU> I will take a look. Thanks. Note that 1.52 is on ftp.cs.unlv.edu. You may want to wait until the weekend since 1.53 may be out by then. -john >The Chimera.ad file that comes with 1.51 lists the following: > > *urldisplay.displayCaret: true > *urldisplay.editType: read > > *titledisplay.displayCaret: False > *titledisplay.editType: read > >Since these are actually resources of the "text" widget, they should probably >be listed as: > > *urldisplay*displayCaret: true > *urldisplay*editType: read > > *titledisplay*displayCaret: False > *titledisplay*editType: read ------- Message 82 Received: from charles.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa16193; 25 May 94 22:40 PDT To: paul@vix.com cc: bug-chimera@cs.unlv.edu Subject: Re: bugs in chimera 1.52 In-reply-to: Your message of "Wed, 25 May 1994 17:47:26 PDT." <9405260047.AA03239@office> Date: Wed, 25 May 1994 22:40:56 -0700 From: John Kilburg <john@charles.CS.UNLV.EDU> >1. clicking "source" over and over causes the displayed text to change (grow). I am not going to worry about this one. Maybe someone wants to see the source of the HTML that lists the source. >2. "make install" created /app-defaults and /app-defaults/Chimera rather than > /usr/X11/lib/X11/app-defaults/Chimera. > >3. a lot of library functions are used without any "extern"'ing, so the compil > complains about quite a few implicit function definitions. I'll look into these. Thanks for the report. -john ------- Message 83 Received: from hslrswi.hasler.ascom.ch by JIMI.CS.UNLV.EDU id aa29318; 26 May 94 3:28 PDT Received: from autelca.ascom.ch by hslrswi.hasler.ascom.ch (8.6.8.1/6.33) id MAA04682; Thu, 26 May 1994 12:29:00 +0200 Received: from case2.autelca.ascom.ch by autelca.ascom.ch (4.1/SMI-4.1) id AA23792; Thu, 26 May 94 12:28:58 +0200 Received: from sun31.autelca.ascom.ch by case2.autelca.ascom.ch (4.1/SMI-4.1) id AA03898; Thu, 26 May 94 12:28:57 +0200 Date: Thu, 26 May 94 12:28:57 +0200 From: Peter TEX Weigand <pweigand@autelca.ascom.ch> Message-Id: <9405261028.AA03898@case2.autelca.ascom.ch> To: bug-chimera@cs.unlv.edu Subject: local help -> core dump Hi Maybe it's an old failure but if you click on help and having the help file local it... In the url.c:MakeURLParts is hostname and port of URLParts *r not initialised. Remove the line 296 "if (!NullString(up1->hostname) || !NullString(up2->hostname))" and it should work. Cheers TEX ________________________________________________________________________________ ascom Autelca AG Peter TEX Weigand VOICE: +41 31 999 6323 Software Card Reader FAX: +41 31 999 6544 Worbstrasse 201 UUCP: ..!uunet!mcsun!chsun!hslrswi!aut!pweigand CH-3073 Guemligen, Switzerland EMAIL: pweigand@autelca.ascom.ch ******************************************************************************** ------- Message 84 Received: from igw.merck.com by JIMI.CS.UNLV.EDU id aa22254; 26 May 94 9:11 PDT Received: by igw.merck.com with rsmtp; Thu, 26 May 1994 12:15:21 EDT Date: Thu, 26 May 1994 12:06:47 -0400 From: Anthony Starks <anthony_starks@merck.com> To: bug-chimera@cs.unlv.edu Subject: bad gohper URL 1.52 fails to load: gopher://is.internic.net/11/infoguide/beginners ------- Message 85 Received: from wolf.arl.mil by JIMI.CS.UNLV.EDU id aa07795; 26 May 94 13:51 PDT Date: Thu, 26 May 94 16:28:47 EDT From: "Lee A. Butler" <butler@arl.mil> To: bug-chimera@cs.unlv.edu Subject: Document Title handling bug Message-ID: <9405261628.aa15010@wolf.arl.mil> There is a problem displaying the title of documents which have the title specified as follows: <title> A Title for My Document In these cases, the chimera "Title:" line is blank. By contrast, documents which specify the title as: A Title for My Document have the title displayed appropriately. Fix (relative to V1.52): main.c 410a411,416 > register char *p; > > /* make title a single line if possible */ > while (isascii(*title) && isspace(*title)) title++; > p = &title[strlen(title)]; > while (--p > title && isascii(*p) && isspace(*title)) *p = '\0'; ------- Message 86 Received: from wolf.arl.mil by JIMI.CS.UNLV.EDU id aa09618; 26 May 94 14:10 PDT Date: Thu, 26 May 94 16:37:58 EDT From: "Lee A. Butler" To: bug-chimera@cs.unlv.edu Subject: config/Imakefile changes Message-ID: <9405261637.aa15546@wolf.arl.mil> I like to be able to install chimera in the X11 souce/binary trees just like any other X application. This required that I *NOT* run the config script, and the following changes be made by hand to Common.tmpl: CHIMERABIN = /usr/X11/bin CHIMERALIB = /usr/X11/lib/X11/chimera CHIMERAMAN = /usr/X11/man/man1 Lee A. Butler Attn: AMSRL-SL-BV U.S. Army Research Laboratory Internet: butler@brl.mil Aberdeen Proving Ground, MD 21005-5068 Phone: (410) 278-9200 ------- Message 87 Received: from enst.enst.fr by JIMI.CS.UNLV.EDU id aa09785; 26 May 94 14:15 PDT Received: from ulysse.enst.fr (inf.enst.fr) by enst.enst.fr (4.1/SMI-4.0) id AA25692; Thu, 26 May 94 23:15:50 +0200 Return-Path: Organization: Ecole Nationale Superieure des Telecommunications, Paris Received: from mistral.enst.fr by ulysse.enst.fr (4.1/SMI-4.0) id AA03351; Thu, 26 May 94 23:15:52 +0200 From: Nicolas Pioch Message-Id: <9405262115.AA03351@ulysse.enst.fr> Subject: Re: Document Title handling bug To: "Lee A. Butler" Date: Thu, 26 May 1994 23:15:50 +0200 (MET DST) Cc: bug-chimera@cs.unlv.edu In-Reply-To: <9405261628.aa15010@wolf.arl.mil> from "Lee A. Butler" at May 26, 94 04:28:47 pm X-My-Email: Nicolas.Pioch@enst.fr pioch@fr.net X-Www: http://mistral.enst.fr/~pioch/ X-Face: Need no lame BW 2x2 xface bitmap. Check out the WWW server above. X-Pgp-Key: available, "finger -l pioch@inf.enst.fr" for my public key. X-Nap: Question: Man Invented Alcohol, God Invented Grass. Who do you trust? X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 450 [Lee A. Butler] | There is a problem displaying the title of documents which have the title | specified as follows: Thanks, that was one of my 1.51 bugs! If you have free time, why doesn't chimera even try to download the inlined image in: http://mistral.enst.fr/~pioch/louvre/paintings/rembrandt/ It works fine with Mosaic, and NCSA httpd access_log proves that chimera doesn't even try to download the thumbnail... weird! Regards - -- Nicolas ------- Message 88 Received: from enst.enst.fr by JIMI.CS.UNLV.EDU id aa11230; 26 May 94 14:40 PDT Received: from ulysse.enst.fr (inf.enst.fr) by enst.enst.fr (4.1/SMI-4.0) id AA26270; Thu, 26 May 94 23:40:34 +0200 Return-Path: Organization: Ecole Nationale Superieure des Telecommunications, Paris Received: from mistral.enst.fr by ulysse.enst.fr (4.1/SMI-4.0) id AA04018; Thu, 26 May 94 23:40:37 +0200 From: Nicolas Pioch Message-Id: <9405262140.AA04018@ulysse.enst.fr> Subject: Re: config/Imakefile changes To: "Lee A. Butler" Date: Thu, 26 May 1994 23:40:35 +0200 (MET DST) Cc: bug-chimera@cs.unlv.edu In-Reply-To: <9405261637.aa15546@wolf.arl.mil> from "Lee A. Butler" at May 26, 94 04:37:58 pm X-My-Email: Nicolas.Pioch@enst.fr pioch@fr.net X-Www: http://mistral.enst.fr/~pioch/ X-Face: Need no lame BW 2x2 xface bitmap. Check out the WWW server above. X-Pgp-Key: available, "finger -l pioch@inf.enst.fr" for my public key. X-Nap: If time heals all wounds, how come the belly button stays the same? X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 732 [Lee A. Butler] | I like to be able to install chimera in the X11 souce/binary trees just like | any other X application. This required that I *NOT* run the config script, | and the following changes be made by hand to Common.tmpl: | | CHIMERABIN = /usr/X11/bin | CHIMERALIB = /usr/X11/lib/X11/chimera | CHIMERAMAN = /usr/X11/man/man1 Well, get rid of the CHIMERA* as well, then. Just use $(BINDIR), $(LIBDIR), etc. And use X standard way to install a man page, that is, have chimera.man in the distribution, which will probably get installed as ProjectRoot/man/mann/chimera.n after imake preprocessing. I have my current X source tree in /usr/X11R6 for instance, other people may be using /usr/local/X* - -- Nicolas ------- Message 89 Received: from wolf.arl.mil by JIMI.CS.UNLV.EDU id aa14068; 26 May 94 15:25 PDT Date: Thu, 26 May 94 18:06:40 EDT From: "Lee A. Butler" To: bug-chimera@cs.unlv.edu Subject: Re: Document Title Bug Message-ID: <9405261806.aa16853@wolf.arl.mil> In my haste to provide the fix to the Document title problem, I forgot the most important diff of all. This is relative to the 1.51 sources libhtmlw/HTMLformat.c: 3130c3130,3152 < hw->html.title = TitleText; - --- > > if (TitleText) { > /* lop off any whitespace at the > * begining of the title > */ > while (*TitleText && > isascii(*TitleText) && > isspace(*TitleText)) > TitleText++; > > hw->html.title = TitleText; > > /* lop off any whitespace at the end > * of the title > */ > TitleText = &TitleText[strlen(TitleText)]; > while (--TitleText > hw->html.title && > isascii(*TitleText) && > isspace(*TitleText)) > *TitleText == '\0'; > } else > hw->html.title = TitleText; > This patch is sub-optimal in my mind, since it is a modification to the NCSA HTML widget code. As far as I can tell, chimera is being "sneaky" and is stealing the pointer to the HTML widget "title" element and using it directly. While this saves a memory move (a good thing) it makes patches like this difficult to maintain. Lee A. Butler Attn: AMSRL-SL-BV U.S. Army Research Laboratory Internet: butler@brl.mil Aberdeen Proving Ground, MD 21005-5068 Phone: (410) 278-9200 ------- Message 90 Received: from wolf.arl.mil by JIMI.CS.UNLV.EDU id aa22028; 26 May 94 17:59 PDT Date: Thu, 26 May 94 20:56:49 EDT From: "Lee A. Butler" To: bug-chimera@cs.unlv.edu Subject: Re: Document Title bug Message-ID: <9405262056.aa18222@wolf.arl.mil> Sigh. Next time I will test my patches on ALL our platforms before I post the patch to the list. Please disregard my previous patch (the one for libhtmlw/HTMLformat.c) and substitute this one. It seems that the widget does a free() on html.title, so it must be the same pointer that was gotten via malloc(). The problem didn't show up until I tried running chimera on my SGI. % diff HTMLformat.c HTMLformat.c.orig 3130,3164d3129 < < if (TitleText) { < register char *p, *q; < < /* lop off any whitespace at the < * begining of the title < */ < q = p = TitleText; < while (*p && isascii(*p) && < isspace(*p)) < p++; < < if (q != p) { < /* copy the string "down" in < * memory, and lop off any < * whitespace at the end < * of the title. < */ < while (*p && < *p != '\n' && < *p != '\r') < *q++ = *p++; < *q = '\0'; < } else { < /* don't have to copy string, < * but we may need to truncate < * it a bit. < */ < p = &TitleText[strlen(TitleText)]; < while (--p > TitleText && < isascii(*p) && < isspace(*p)) < *p = '\0'; < } < } Lee A. Butler Attn: AMSRL-SL-BV U.S. Army Research Laboratory Internet: butler@brl.mil Aberdeen Proving Ground, MD 21005-5068 Phone: (410) 278-9200 ------- Message 91 Received: from charles.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa12947; 27 May 94 2:15 PDT To: Nicolas Pioch cc: bug-chimera@cs.unlv.edu Subject: Re: Document Title handling bug In-reply-to: Your message of "Thu, 26 May 1994 23:15:50 +0200." <9405262115.AA03351@ulysse.enst.fr> Date: Fri, 27 May 1994 02:15:18 -0700 From: John Kilburg >[Lee A. Butler] > | There is a problem displaying the title of documents which have the title > | specified as follows: > >Thanks, that was one of my 1.51 bugs! >If you have free time, why doesn't chimera even try to download the inlined >image in: > http://mistral.enst.fr/~pioch/louvre/paintings/rembrandt/ > >It works fine with Mosaic, and NCSA httpd access_log proves that chimera >doesn't even try to download the thumbnail... weird! The above URL works fine with 1.52 and what will be 1.53. -john ------- Message 92 Received: from charles.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa14280; 27 May 94 2:46 PDT To: bug-chimera@cs.unlv.edu Subject: Re: Document Title handling bug In-reply-to: Your message of "Thu, 26 May 1994 16:28:47 EDT." <9405261628.aa15010@wolf.arl.mil> Date: Fri, 27 May 1994 02:46:46 -0700 From: John Kilburg >There is a problem displaying the title of documents which have the title This problem has been fixed. In another mail message it was said that chimera was "sneaking" the string away (or something like that). As far as I know I just grabbed the value with XtGetValues as usual. Modification of the HTML widget is not needed. If this is incorrect, please let me know. -john ------- Message 93 Received: from nova.gmi.edu by JIMI.CS.UNLV.EDU id aa20359; 27 May 94 4:19 PDT Received: by nova.gmi.edu (4.1/SMI-4.1-DNI) id AA01502; Fri, 27 May 94 07:22:20 EDT Date: Fri, 27 May 1994 07:22:20 -0400 (EDT) From: "R. Stewart Ellis" Subject: Re: Document Title handling bug To: bug-chimera@cs.unlv.edu In-Reply-To: <9405270929.AA01011@nova.gmi.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 27 May 1994, John Kilburg wrote: > >[Lee A. Butler] > > | There is a problem displaying the title of documents which have the title > > | specified as follows: > > > >Thanks, that was one of my 1.51 bugs! > >If you have free time, why doesn't chimera even try to download the inlined > >image in: > > http://mistral.enst.fr/~pioch/louvre/paintings/rembrandt/ > > > >It works fine with Mosaic, and NCSA httpd access_log proves that chimera > >doesn't even try to download the thumbnail... weird! > > The above URL works fine with 1.52 and what will be 1.53. > > -john > It also works for me with 1.51 on SunOS 5.1 SPARC over term, both with and without the closing slash. R.Stewart(Stew) Ellis, Assoc.Prof., (Off)313-762-9765 ___________________ Humanities & Social Science, GMI Eng.& Mgmt. Inst. / _____ ______ Flint, MI 48504 ellis@nova.gmi.edu / / / / / / Gopher,chimera,nn,tin,jove,modems, free code is best!/________/ / / / / ------- Message 94 Received: from sun2.nsfnet-relay.ac.uk by JIMI.CS.UNLV.EDU id aa26798; 27 May 94 6:42 PDT Via: uk.ac.aston; Fri, 27 May 1994 14:16:02 +0100 Received: from caledfwlch.aston.ac.uk by email.aston.ac.uk with SMTP (PP) id <00932-0@email.aston.ac.uk>; Fri, 27 May 1994 14:14:05 +0100 Received: by caledfwlch.aston.ac.uk (Smail3.1.28.1 #2) id m0q71mw-0000dJC; Fri, 27 May 94 14:17 BST Message-Id: To: bug-chimera@charles.CS.UNLV.EDU Bcc: Subject: Re:local files with Chimera 1.52 & core dumps X-Mailer: exmh version 1.3 4/7/94 Date: Fri, 27 May 1994 14:17:25 +0100 From: Gareth Owen I got the same problem (Sparc4/SunOS4.1.1/gcc2.5.8) with the help file. The bundled compiler produces the same results The problems are with memory allocation in url.c when it creates the url for the file in MakeURL() and are ... (1) when calculating how much space needed (line 209), if up->hostname == NULL , then strlen(up->hostname) will cause a core dump as (from man page) "On the Sun processor, as well as on many other machines, you can not use a NULL pointer to indicate a null string. A NULL pointer is an error and results in an abort of the pro- gram. " (2) (line 212) I think up->port == -1 should be true if it's a file. It isn't and a spurious value gets inserted in the url (3) gcc is none too comfortable with creating a string without allocating memory (lines 200-208) e.g., Doesn't like delim="//" Does like delim=strdup("//"); It compiles ok but falls over when run. (4) It seems to tickle something in the Sun implementation of malloc and friends but gdb can't tell me anything useful since I haven't got the source. I needed to link in GNU malloc to get a result. Here's the diffs , make CFLAGS+="-DWTFGO=1" for best results. 201,214d199 < #ifdef WTFGO < if (addext) ext = strdup(up->ext); < else ext = strdup(""); < < if (!NullString(up->hostname)) < delim = strdup("//"); < else { < delim = strdup(""); < up->hostname=strdup(""); < } < < if (NullString(up->filename)) filename = strdup("/"); < else filename = strdup(up->filename); < #else 223,227d207 < #endif < < #ifdef WTFGO < if (! up->method) up->method=strdup(""); < #endif 229c209 < len = strlen(up->method) + strlen(up->hostname) + strlen(filename) + - --- > len = strlen(up->method) + strlen(up->hostname) + strlen(up->filename) + 231d210 < 233,236d211 < < #ifdef WTFGO < if ((up->port == -1) || (! strcmp(up->method,"file"))) < #else 238d212 < #endif ------- Message 95 Received: from ISC.TAMU.EDU by JIMI.CS.UNLV.EDU id aa13372; 27 May 94 12:51 PDT Received: from trustworthy.isc.tamu.edu (TRUSTWORTHY.ISC.TAMU.EDU [128.194.13.179]) by isc.tamu.edu (8.6.8/8.6.4) with ESMTP id OAA04296 for ; Fri, 27 May 1994 14:51:42 -0500 From: Alan Peery Received: (peery@localhost) by trustworthy.isc.tamu.edu (8.6.8/8.6.4) id OAA16462 for bug-chimera@cs.unlv.edu; Fri, 27 May 1994 14:49:31 -0500 Date: Fri, 27 May 1994 14:49:31 -0500 Message-Id: <199405271949.OAA16462@trustworthy.isc.tamu.edu> To: bug-chimera@cs.unlv.edu Subject: Announcement of Chimera 1.51 John et al, I read your announcement on comp.infosystems.announce on your release of 1.51. You left off the most important information--how does it differ from NCSA Mosaic? You might also want to include a list of the platforms that you have run it on successfully. Alan Alan Peery Institute for Scientific Computation Texas A&M University peery@isc.tamu.edu ------- Message 96 Received: from relay3.UU.NET by JIMI.CS.UNLV.EDU id aa19916; 27 May 94 15:33 PDT Received: from uucp4.uu.net by relay3.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA05626; Fri, 27 May 94 18:32:46 -0400 Received: from almserv.UUCP by uucp4.uu.net with UUCP/RMAIL ; Fri, 27 May 1994 18:32:45 -0400 Received: from amazon.fnma.com by fnma.COM (4.1/SMI-4.1) id AA24100; Fri, 27 May 94 17:47:56 EDT Received: from tazmania.fnma.com by amazon.fnma.com (5.0/SMI-SVR4) id AA28249; Fri, 27 May 1994 17:47:53 +0500 Received: by tazmania.fnma.com (5.0/SMI-SVR4) id AA04876; Fri, 27 May 1994 17:47:49 +0500 Date: Fri, 27 May 1994 17:47:49 +0500 From: Ben Taylor Message-Id: <9405272147.AA04876@tazmania.fnma.com> To: ellis@nova.gmi.edu Cc: ellis@nova.gmi.edu, bug-chimera@cs.unlv.edu In-Reply-To: <9402201530.AA12677@nova.gmi.edu> (ellis@nova.gmi.edu) Subject: Re: Try this (new) URL Content-Length: 237 Stew, I've just got Chimera compiled with term for SunOS 4.1.3 and have been reading the bug-chimera list, and saw you mention a term enabled Mosaic. Is that for Sun? I've been trying to find one and have had no success. Thanks Ben ------- Message 97 Received: from charles.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa21187; 27 May 94 16:06 PDT To: Gareth Owen cc: bug-chimera@charles.CS.UNLV.EDU Subject: Re: local files with Chimera 1.52 & core dumps In-reply-to: Your message of "Fri, 27 May 1994 14:17:25 BST." Date: Fri, 27 May 1994 16:06:06 -0700 From: John Kilburg >(1) when calculating how much space needed (line 209), if up->hostname == NULL > then strlen(up->hostname) will cause a core dump as (from man page) > "On the Sun processor, as well as on many other machines, you > can not use a NULL pointer to indicate a null string. A > NULL pointer is an error and results in an abort of the pro- > gram. " Hmmm. Interesting. I thought it was OK to reference a NULL pointer. I'll keep this in mind in the future. :) >(2) (line 212) I think > up->port == -1 > should be true if it's a file. It isn't and a spurious value gets inserted > in the url I'm not sure how this can happen. In every place that a URLParts structure is created port gets initialized to -1. The only reason it will change is if there is port number specified in the URL (or chimera is wiping out memory someplace). >(3) gcc is none too comfortable with creating a string without allocating >memory > (lines 200-208) e.g., > Doesn't like delim="//" > Does like delim=strdup("//"); > It compiles ok but falls over when run. It depends on how delim is used. In MakeURL doing delim="//" shouldn't be a problem. There is a problem with MakeURL that I will fix. I appreciate the bug report and patch. -john ------- Message 98 Received: from wiggins.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa16029; 31 May 94 8:24 PDT To: bug-chimera@wiggins.ISRI.UNLV.EDU Subject: HTML Parsing problem....? Date: Tue, 31 May 1994 08:24:31 -0700 From: Kevin O Grover chimera http://www.scuba.com/scuba/home.html Choose the FAQ option. scroll down a page, choose the "Soda Pop" page (or the one after) and you will be shown the HTML source (instead of the processed information). (Those are the only two I checked, I was looking at this as an example format someone suggested.) Mosaic parses it correctly. - - kevin ------- Message 99 Received: from wolf.arl.mil by JIMI.CS.UNLV.EDU id aa21353; 31 May 94 21:23 PDT Date: Tue, 31 May 94 23:51:24 EDT From: "Lee A. Butler" To: bug-chimera@cs.unlv.edu Subject: Handling Encoding types? Message-ID: <9405312351.aa11671@wolf.arl.mil> Just an FYI, it would appear that chimera does not handle HTTP "encoding" types. For example, it does not expand compressed or gzip'ed documents. To demonstrate this, try getting the following documents: http://hawks.ha.md.us/Compressed.html.Z http://hawks.ha.md.us/Gziped.html.gz A cursory look did not turn up any obvious places where this capability should be added. Lee A. Butler Attn: AMSRL-SL-BV U.S. Army Research Laboratory Internet: butler@brl.mil Aberdeen Proving Ground, MD 21005-5068 Phone: (410) 278-9200 ------- Message 100 Received: from charles.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa23763; 31 May 94 22:30 PDT To: bug-chimera@cs.unlv.edu Subject: Re: Handling Encoding types? In-reply-to: Your message of "Tue, 31 May 1994 23:51:24 EDT." <9405312351.aa11671@wolf.arl.mil> Date: Tue, 31 May 1994 22:30:56 -0700 From: John Kilburg >Just an FYI, it would appear that chimera does not handle HTTP "encoding" >types. For example, it does not expand compressed or gzip'ed documents. To >demonstrate this, try getting the following documents: > > http://hawks.ha.md.us/Compressed.html.Z > http://hawks.ha.md.us/Gziped.html.gz > >A cursory look did not turn up any obvious places where this capability should >be added. I've been stewing about this for awhile. Someone requested it a few of months ago but I've been to lazy to deal with it. I'll start giving it some thought. BTW, look for 1.53 tonight or tomorrow night. -john ------- Message 101 Received: from charles.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa25116; 31 May 94 23:14 PDT To: bug-chimera@cs.unlv.edu Subject: Re: Handling Encoding types? In-reply-to: Your message of "Tue, 31 May 1994 23:51:24 EDT." <9405312351.aa11671@wolf.arl.mil> Date: Tue, 31 May 1994 23:13:59 -0700 From: John Kilburg > http://hawks.ha.md.us/Compressed.html.Z I get errors about this not being a valid hostname. Does anyone else have an example URL which encodes the data? The description is fine and all but I would like to see a real setup that uses it. -john ------- End of Forwarded Messages