Received: from jimi.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa25955; 22 Dec 94 22:54 PST To: jay@JIMI.CS.UNLV.EDU Subject: bug-chimera oct 94 Date: Thu, 22 Dec 1994 22:54:19 -0800 From: Jay Nietling ------- Forwarded Messages Received: from tango.rahul.net by JIMI.CS.UNLV.EDU id aa17197; 1 Oct 94 1:08 PDT Received: from dandelion.com by tango.rahul.net with SMTP id AA05657 (5.67b8/IDA-1.5 for ); Sat, 1 Oct 1994 01:08:27 -0700 Received: (from lnz@localhost) by dandelion.com (8.6.9/8.6.9) id AAA04266; Sat, 1 Oct 1994 00:55:39 -0700 Date: Sat, 1 Oct 1994 00:55:39 -0700 From: "Leonard N. Zubkoff" Message-Id: <199410010755.AAA04266@dandelion.com> To: bug-chimera@cs.unlv.edu Subject: Bug in chimera-giftoppm The lines (in chimera-giftoppm): gray) giftrans -C -B "$back_color" "$filename" | giftoppm | ppmtopgm ;; mono) giftrans -C -B "$back_color" "$filename" | giftoppm |ppmtopgm|pgmtopbm ;; *) giftrans -C -B "$back_color" "$filename" | giftoppm ;; are problematic, as the netpbm package installs a giftopnm but no giftoppm. Changing the above to giftopnm allows inline gif images to work properly. Leonard ------- Message 2 Received: from email.enst.fr by JIMI.CS.UNLV.EDU id aa25843; 1 Oct 94 13:02 PDT Received: from mistral.enst.fr (pioch@mistral.enst.fr [137.194.160.11]) by email.enst.fr (8.6.9/8.6.9) with ESMTP id VAA13630; Sat, 1 Oct 1994 21:02:06 +0100 From: Nicolas Pioch Received: (pioch@localhost) by mistral.enst.fr (8.6.9/8.6.9) id VAA24851; Sat, 1 Oct 1994 21:02:03 +0100 Message-Id: <199410012002.VAA24851@mistral.enst.fr> Subject: Re: Bug in chimera-giftoppm To: "Leonard N. Zubkoff" Date: Sat, 1 Oct 1994 21:02:02 +0100 (MET) Cc: bug-chimera@cs.unlv.edu In-Reply-To: <199410010755.AAA04266@dandelion.com> from "Leonard N. Zubkoff" at Oct 1, 94 00:55:39 am Sensitivity: Confidential X-My-Email: pioch@email.enst.fr pioch@fr.net X-Www: https://mistral.enst.fr/~pioch/ X-Pgp-Key: "finger -l pioch@inf.enst.fr | pgp -fka" X-Domestic-Intelligence: SDI radar NSA FtBragg DES crypt Peking spy DST Kennedy X-Nap: O'Toole's Commentary on Murphy's Law: Murphy was an optimist. X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 1056 [Leonard N. Zubkoff] | are problematic, as the netpbm package installs a giftopnm but no giftoppm. | Changing the above to giftopnm allows inline gif images to work properly. That's my fault over there. (I have installed netpbm on top of pbmplus, so I sometimes fail to differentiate both) If chimera requires netpbm to run, we have to change it to giftopnm as you have explained. About 1.60 release, are the **/Makefile necessary in the distribution? Also, it's much more simple to configure than the previous betas. Good work! Weird problem: it seems that when chimera starts an external viewer (such as playaudio), it freezes after than: - can't exit - can't download another file etc. until the external viewer has exited. Sample URL: https://mistral.enst.fr/~pioch/sounds/ Click on a sound not in the local cache. while it plays, try clicking on an icon at the bottom of the page... it freezes until the sound stops playing! This behavior does not seem to occur when trying to download a file from the cache though. Cheers - -- Nicolas ------- Message 3 Received: from relay3.UU.NET by JIMI.CS.UNLV.EDU id aa20533; 2 Oct 94 6:11 PDT Received: from uucp7.UU.NET by relay3.UU.NET with SMTP id QQxjwm09358; Sun, 2 Oct 1994 09:11:13 -0400 Received: from almserv.UUCP by uucp7.UU.NET with UUCP/RMAIL ; Sun, 2 Oct 1994 09:11:14 -0400 Received: from amazon.fnma.com by fnma.COM (4.1/SMI-4.1) id AA09886; Sun, 2 Oct 94 08:59:14 EDT Received: from tazmania.fnma.com by amazon.fnma.com (5.0/SMI-SVR4) id AA05112; Sun, 2 Oct 1994 08:59:15 -0400 Date: Sun, 2 Oct 1994 08:59:15 -0400 From: Ben Taylor Message-Id: <9410021259.AA05112@amazon.fnma.com> To: uunet!dandelion.com!lnz@uunet.uu.net Subject: Re: Bug in chimera-giftoppm Cc: uunet!cs.unlv.edu!bug-chimera@uunet.uu.net Content-Length: 650 > >The lines (in chimera-giftoppm): > >gray) giftrans -C -B "$back_color" "$filename" | giftoppm | ppmtopgm ;; >mono) giftrans -C -B "$back_color" "$filename" | giftoppm |ppmtopgm|pgmtopbm ;; >*) giftrans -C -B "$back_color" "$filename" | giftoppm ;; > >are problematic, as the netpbm package installs a giftopnm but no giftoppm. >Changing the above to giftopnm allows inline gif images to work properly. As a side question to this, is there a reason that netpbm doesn't have the code for giftoppm, when it has the ppmtogif? Is this an oversight or something? (Me, I just took the code from pbm and stuck it in netpbm....) > > Leonard > Ben ------- Message 4 Received: from cephas.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa01792; 2 Oct 94 14:00 PDT To: Ben Taylor cc: bug-chimera@cephas.ISRI.UNLV.EDU Subject: Re: Bug in chimera-giftoppm In-reply-to: Your message of "Sun, 02 Oct 1994 08:59:15 EDT." <9410021259.AA05112@amazon.fnma.com> Date: Sun, 02 Oct 1994 14:00:33 -0700 From: John Kilburg >>The lines (in chimera-giftoppm): >> >>gray) giftrans -C -B "$back_color" "$filename" | giftoppm | ppmtopgm ;; >>mono) giftrans -C -B "$back_color" "$filename" | giftoppm |ppmtopgm|pgmtopbm ;; >>*) giftrans -C -B "$back_color" "$filename" | giftoppm ;; >> >>are problematic, as the netpbm package installs a giftopnm but no giftoppm. >>Changing the above to giftopnm allows inline gif images to work properly. > >As a side question to this, is there a reason that netpbm doesn't have the cod e >for giftoppm, when it has the ppmtogif? Is this an oversight or something? >(Me, I just took the code from pbm and stuck it in netpbm....) pnm - portable anymap file format The pnm programs operate on portable bitmaps, graymaps, and pixmaps, produced by the pbm, pgm, and ppm segments. There is no file format associated with pnm itself. Just make a link from giftoppm to giftopnm and you'll be in good shape or just use giftopnm as described above. -john ------- Message 5 Received: from igw.merck.com by JIMI.CS.UNLV.EDU id aa13886; 3 Oct 94 13:34 PDT Received: by igw.merck.com (5.65/fma-120691); id AA05021; Mon, 3 Oct 94 16:40:42 -0400 Message-Id: <9410032040.AA05021@igw.merck.com> Date: Mon, 3 Oct 1994 16:26:50 -0400 From: Anthony Starks To: bug-chimera@cs.unlv.edu Subject: 1.60 URL bugs go to https://rs6.loc.gov/cwarquery.html enter a query, say surrender get a list of hits, and what chimera bomb when attempting to load the document. The returned URLs look like this: https://rs6.loc.gov/cgi-bin/query/1?cwar:./temp/~xN7p::surrend ------- Message 6 Received: from cephas.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa12434; 4 Oct 94 2:11 PDT To: Anthony Starks cc: bug-chimera@cs.unlv.edu Subject: Re: 1.60 URL bugs In-reply-to: Your message of "Mon, 03 Oct 1994 16:26:50 EDT." <9410032040.AA05021@igw.merck.com> Date: Tue, 04 Oct 1994 02:11:27 -0700 From: John Kilburg >go to > https://rs6.loc.gov/cwarquery.html > >enter a query, say surrender >get a list of hits, and what chimera bomb when attempting to >load the document. The returned URLs look like this: > > https://rs6.loc.gov/cgi-bin/query/1?cwar:./temp/~xN7p::surrend Fixed. I'll make it available in 1.61. -john ------- Message 7 Received: from cheviot.ncl.ac.uk by JIMI.CS.UNLV.EDU id aa29654; 6 Oct 94 4:53 PDT Received: from aire.ncl.ac.uk by cheviot.ncl.ac.uk id (5.65cVUW/NCL-CMA.1.35 for ) with SMTP; Thu, 6 Oct 1994 12:53:17 +0100 From: "J.D.Coleman" Message-Id: Subject: Forms fixes To: Chimera Bugs Mailing List Date: Thu, 6 Oct 1994 12:53:13 +0100 (BST) Organisation: University of Newcastle Computing Service X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1353 I've fixed a couple of minor bugs in the forms handling code (EscapeURL). First, the '+' character was being left alone and not escaped. Second, I've changed the 'char' types to 'unsigned char', as new Sun keyboards can generate 8-bit 'ASCII' and that broke the previous escaping. Diffs follow. J - -- - -- Julian Coleman, Computing Service, | j.d.coleman@newcastle.ac.uk - -- Claremont Tower, University of Newcastle, | as967@cleveland.freenet.edu - -- Newcastle upon Tyne, NE1 7RU, England. | - - - - - - - - - - - - - - - -- Tel +44-191-222-8068 Fax +44-191-222-8765 | Be wery, wery careful Wabbit ---8<---------------------------- Cut here ---------------------------->8--- - --- orig/src/url.c Wed Sep 28 08:16:36 1994 +++ src/url.c Thu Oct 6 12:28:57 1994 @@ -100,9 +100,9 @@ char *url; int s2p; { - - char *cp; - - char *n, *s; - - static char *hex = "0123456789ABCDEF"; /* back to my C64 days... */ + unsigned char *cp; + unsigned char *n, *s; + static unsigned char *hex = "0123456789ABCDEF"; /* back to my C64 days... */ /* * use a bit of memory so i don't have to mess around here @@ -119,7 +119,7 @@ { *cp = '+'; } - - if (*cp <= ' ' || *cp == '%' || *cp == '&' || *cp == '=') + else if (*cp <= ' ' || *cp == '%' || *cp == '&' || *cp == '=' || *cp == '+') { *n = '%'; n++; ------- Message 8 Received: from citi.umich.edu by JIMI.CS.UNLV.EDU id aa02412; 6 Oct 94 6:02 PDT Received: from citi.umich.edu by citi.umich.edu for bug-chimera@cs.unlv.edu with SMTP; Thu, 06 Oct 94 09:01:34 -0400 From: Jim.Rees@umich.edu To: Chimera Bugs Mailing List Date: Thu, 06 Oct 94 09:01:26 EDT Subject: Re: Forms fixes Sender: rees@citi.umich.edu In-Reply-To: "J.D.Coleman", Thu, 06 Oct 94 12:53:13 BST Second, I've changed the 'char' types to 'unsigned char', as new Sun keyboards can generate 8-bit 'ASCII' and that broke the previous escaping. If I understand it correctly, your fix will probably work but is technically wrong. The html character set is ascii, and 8-bit characters are illegal, escaped or not. If you've typed 8-bit characters then what you probably meant was some 8859-1 character, which I think (not being intimately familiar with the spec) should be escaped in a completely different way, possibly the same way it's done in html text (ó). The reason it will probably work is that the server will simply un-escape it, and if the server is 8859-1 too (which is very likely) then everyone's happy. I'm not extremely sure about any this. ------- Message 9 Received: from email.enst.fr by JIMI.CS.UNLV.EDU id aa02932; 6 Oct 94 6:24 PDT Received: from blizzard.enst.fr (pioch@blizzard.enst.fr [137.194.160.47]) by cyclone (8.6.9/8.6.9) with ESMTP id OAA02827; Thu, 6 Oct 1994 14:24:15 +0100 From: Nicolas Pioch Received: (pioch@localhost) by blizzard.enst.fr (8.6.9/8.6.9) id OAA09162; Thu, 6 Oct 1994 14:24:11 +0100 Message-Id: <199410061324.OAA09162@blizzard.enst.fr> Subject: Re: Forms fixes To: Jim.Rees@umich.edu Date: Thu, 6 Oct 1994 14:24:10 +0100 (MET) Cc: bug-chimera@cs.unlv.edu In-Reply-To: <199410061315.OAA11381@ulysse.enst.fr> from "Jim.Rees@umich.edu" at Oct 6, 94 09:01:26 am Sensitivity: Confidential X-My-Email: pioch@email.enst.fr pioch@fr.net X-Www: https://mistral.enst.fr/~pioch/ X-Pgp-Key: "finger -l pioch@inf.enst.fr | pgp -fka" X-Domestic-Intelligence: SDI radar NSA FtBragg DES crypt Peking spy DST Kennedy X-Nap: If ignorance is bliss, why aren't there more happy people? X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 832 [Jim.Rees@umich.edu] | wrong. The html character set is ascii, and 8-bit characters are illegal, Yikes! Nah, the HTML character set is full 8bits ISO-Latin-1. For instance, my Web server (developped on X/Unix) has iso-latin1 chars directly embedded, I don't use the HTML escape sequences &thing; anymore since I've seen that some clients don't accept them (for instance, most clients don't interpret &stuff; in fields). &blah; things are only usuful when developping web pages on a machine whose native character set is not ISO-Latin-1, for instance on a Mac or on some EBCDIC thinggy. Also, it's the client's work to convert ISO-Latin-1 8bits chars to the client machine local representation. For instance, MacWeb converts automagically french iso-latin-1 accented letters into their Mac counterpart... - -- Nicolas ------- Message 10 Received: from cheviot.ncl.ac.uk by JIMI.CS.UNLV.EDU id aa04752; 6 Oct 94 7:33 PDT Received: from aire.ncl.ac.uk by cheviot.ncl.ac.uk id <PAA10530@cheviot.ncl.ac.uk> (8.6.9/ for ncl.ac.uk) with SMTP; Thu, 6 Oct 1994 15:33:27 +0100 From: "J.D.Coleman" <J.D.Coleman@newcastle.ac.uk> Message-Id: <AA07754.9410061433@aire.ncl.ac.uk> Subject: Re: Forms fixes To: Chimera Bugs Mailing List <bug-chimera@cs.unlv.edu> Date: Thu, 6 Oct 1994 15:33:24 +0100 (BST) In-Reply-To: <199410061324.OAA09162@blizzard.enst.fr> from "Nicolas Pioch" at Oct 6, 94 02:24:10 pm Organisation: University of Newcastle Computing Service X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1491 Nicolas Pioch <pioch@Email.ENST.Fr> writes : > [Jim.Rees@umich.edu] > | wrong. The html character set is ascii, and 8-bit characters are illegal, > > Yikes! > > Nah, the HTML character set is full 8bits ISO-Latin-1. Can someone point me to some definitive documentation? From what I've read - https://www.utirc.utoronto.ca/HTMLdocs/NewHTML/entities.html (Special Characters in HTML ) HTML allows special character entities to represent the ISO-Latin-1 characters that may not be available on a standard keyboard. They are represented by &<string>; e.g. " is the " character. https://info.cern.ch/hypertext/WWW/MarkUp/HTMLPlus/htmlplus_42.html (Sending form data to an HTTP server) =, & and space charcters should be escaped by a % followed by the hex representation of the character, e.g. space becomes %20. I seem to remmeber that the NCSA documentation is a little more detailed, e.g. has the space to plus conversion in, but I don't remember reading anything saying that 8-bit characters were illegal in form requests or cannot be included in documents. Feel free to correct me. I'd check the NCSA docs now, but I can't get a connection at the moment. J - -- - -- Julian Coleman, Computing Service, | j.d.coleman@newcastle.ac.uk - -- Claremont Tower, University of Newcastle, | as967@cleveland.freenet.edu - -- Newcastle upon Tyne, NE1 7RU, England. | - - - - - - - - - - - - - - - -- Tel +44-191-222-8068 Fax +44-191-222-8765 | Be wery, wery careful Wabbit ------- Message 11 Received: from email.enst.fr by JIMI.CS.UNLV.EDU id aa05226; 6 Oct 94 7:49 PDT Received: from blizzard.enst.fr (pioch@blizzard.enst.fr [137.194.160.47]) by cyclone (8.6.9/8.6.9) with ESMTP id PAA05500; Thu, 6 Oct 1994 15:48:59 +0100 From: Nicolas Pioch <pioch@Email.ENST.Fr> Received: (pioch@localhost) by blizzard.enst.fr (8.6.9/8.6.9) id PAA09460; Thu, 6 Oct 1994 15:48:56 +0100 Message-Id: <199410061448.PAA09460@blizzard.enst.fr> Subject: Re: Forms fixes To: "J.D.Coleman" <J.D.Coleman@newcastle.ac.uk> Date: Thu, 6 Oct 1994 15:48:54 +0100 (MET) Cc: bug-chimera@cs.unlv.edu In-Reply-To: <AA07754.9410061433@aire.ncl.ac.uk> from "J.D.Coleman" at Oct 6, 94 03:33:24 pm Sensitivity: Confidential X-My-Email: pioch@email.enst.fr pioch@fr.net X-Www: https://mistral.enst.fr/~pioch/ X-Pgp-Key: "finger -l pioch@inf.enst.fr | pgp -fka" X-Domestic-Intelligence: SDI radar NSA FtBragg DES crypt Peking spy DST Kennedy X-Nap: In 1880 the French captured Detroit but gave it back ... they couldn't get parts. X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 3069 [J.D.Coleman] | Can someone point me to some definitive documentation? Extract from the HTML+ DTD (there may be an update around) The first paragraph is what you're looking for. - -- Nicolas HTML+ Document Format Dave Raggett Internet Draft Hewlett Packard <draft-raggett-www-html-00.txt> 28th October 1993 [...] 5.1 Character Sets and Entity Definitions By default, HTML+ documents are made up of 8-bit characters from the ISO 8859 Latin-1 character set. The network protocol used to retrieve documents may translate the character set into a locally acceptable form, e.g. EBCDIC. The HTTP protocol uses the MIME standard (RFC 1341) to specify the document type and character set. ISO SGML entity definitions are used to include characters which are missing from the character set or which would otherwise be confused with markup elements, e.g: & ampersand & < less than sign < > greater than sign > " the double quote sign " Appendix II lists a broad range of characters and symbols, relating their ISO names to the corresponding character codes in common character sets. They allow authors to include accented characters in 7-bit ASCII documents. Some other useful entity definitions are: – en dash (half the width of an em unit) — em dash (equal to width of an "m" character)   en space   em space   non breaking space ­ soft hyphen (normally invisible) © copyright sign ™ trade mark sign ® registered sign There are a large number of entities defined by the ISO, covering most languages and symbols for publishing and mathematics. Requiring all browsers to support these would be impractical, e.g. how should a dumb terminal show such symbols. In some cases there will be accepted ways of mapping them to normal characters, e.g. as ae and e as e. Perhaps the safest recommendation is that where authors need to use a specialised character or symbol, they should use ISO entity names rather than inventing their own. Browsers should leave unrecognised entity names untranslated. In some cases it is useful to specify the language used in a given element, with the LANG attribute. The ISO defines abbreviations for most languages, e.g. FR for french as in: <Q LANG="FR">Je m'aveugle.</Q>. This attribute permits language dependent layout and hyphenation decisions, e.g. Hebrew uses right to left word order. To allow SGML parsers to recognise entity names, authors should declare them before use, for example: <!ENTITY % ISOcyr1 PUBLIC "ISO 8879-1986//ENTITIES Russian Cyrillic/EN"> %ISOcyr1; This introduces ISOcyr1 as a local name for the ISO public identifier for the cyrillic alphabet and then includes the associated set of entity definitions as part of the current document. This declaration is unnecessary for entities defined within the HTML+ DTD. ------- Message 12 Received: from citi.umich.edu by JIMI.CS.UNLV.EDU id aa04511; 6 Oct 94 14:54 PDT Received: from [141.211.128.188] by citi.umich.edu for bug-chimera@cs.unlv.edu with SMTP; Thu, 06 Oct 94 17:53:13 -0400 From: Jim.Rees@umich.edu To: bug-chimera@cs.unlv.edu Date: Thu, 06 Oct 1994 17:53:12 -0400 Subject: Re: Forms fixes Sender: rees@citi.umich.edu In-Reply-To: Nicolas Pioch, Thu, 06 Oct 1994 15:48:54 BST By default, HTML+ documents are made up of 8-bit characters from the ISO 8859 Latin-1 character set. I stand corrected. Having fought this battle with mail and news, it didn't occur to me that they might have done something reasonable like this. Thanks for providing the reference, too. I just tried pasting some 8859-1 into a form in Mosaic, and the text wouldn't even paste in right. Add this to the growing list of things that chimera does right and Mosaic doesn't. I'll be applying J. D.'s fix tonight. ------- Message 13 Received: from citi.umich.edu by JIMI.CS.UNLV.EDU id aa04803; 6 Oct 94 14:56 PDT Received: from [141.211.128.188] by citi.umich.edu for bug-chimera@cs.unlv.edu with SMTP; Thu, 06 Oct 94 17:55:54 -0400 From: Jim.Rees@umich.edu To: bug-chimera@cs.unlv.edu Date: Thu, 06 Oct 1994 17:55:54 -0400 Subject: truncated inlines? Sender: rees@citi.umich.edu Chimera 1.60 running on mach 2.5 sometimes truncates inline images. Usually only the top half or third of the image is visible, with the bottom either all black or all white. It's apparently not an X server bug. Has anyone else seen this? ------- Message 14 Received: from email.enst.fr by JIMI.CS.UNLV.EDU id aa12296; 6 Oct 94 15:48 PDT Received: from blizzard.enst.fr (pioch@blizzard.enst.fr [137.194.160.47]) by cyclone (8.6.9/8.6.9) with ESMTP id XAA13478; Thu, 6 Oct 1994 23:48:38 +0100 From: Nicolas Pioch <pioch@Email.ENST.Fr> Received: (pioch@localhost) by blizzard.enst.fr (8.6.9/8.6.9) id XAA11528; Thu, 6 Oct 1994 23:48:34 +0100 Message-Id: <199410062248.XAA11528@blizzard.enst.fr> Subject: Re: truncated inlines? To: Jim.Rees@umich.edu Date: Thu, 6 Oct 1994 23:48:33 +0100 (MET) Cc: bug-chimera@cs.unlv.edu In-Reply-To: <199410062239.XAA24656@ulysse.enst.fr> from "Jim.Rees@umich.edu" at Oct 6, 94 05:55:54 pm Sensitivity: Confidential X-My-Email: pioch@email.enst.fr pioch@fr.net X-Www: https://mistral.enst.fr/~pioch/ X-Pgp-Key: "finger -l pioch@inf.enst.fr | pgp -fka" X-Domestic-Intelligence: SDI radar NSA FtBragg DES crypt Peking spy DST Kennedy X-Nap: Always borrow money from a pessimist; he doesn't expect to be paid back. X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 658 [Jim.Rees@umich.edu] | Chimera 1.60 running on mach 2.5 sometimes truncates inline images. Usually | only the top half or third of the image is visible, with the bottom either | all black or all white. It's apparently not an X server bug. Has anyone | else seen this? I haven't seen images truncated, but they sometimes (1% of the time?) don't appear, and a "X" gets printed instead. Reloading the page seems to solve the problem. Also, 1.60 prints something like "NNNNNN bytes loaded out of 486402" at the top, whereas each page is only a few bytes/kb long, and there are only tiny gifs inlined. Is that the byte count in the cache or... ? - -- N. ------- Message 15 Received: from email.enst.fr by JIMI.CS.UNLV.EDU id aa12873; 6 Oct 94 16:04 PDT Received: from blizzard.enst.fr (pioch@blizzard.enst.fr [137.194.160.47]) by cyclone (8.6.9/8.6.9) with ESMTP id AAA13597 for <bug-chimera@charles.cs.unlv.edu>; Fri, 7 Oct 1994 00:04:03 +0100 From: Nicolas Pioch <pioch@Email.ENST.Fr> Received: (pioch@localhost) by blizzard.enst.fr (8.6.9/8.6.9) id AAA11710 for bug-chimera@charles.cs.unlv.edu; Fri, 7 Oct 1994 00:03:59 +0100 Message-Id: <199410062303.AAA11710@blizzard.enst.fr> Subject: GIF89a with transparent background To: Chimera fans <bug-chimera@charles.cs.unlv.edu> Date: Fri, 7 Oct 1994 00:03:58 +0100 (MET) Sensitivity: Confidential X-My-Email: pioch@email.enst.fr pioch@fr.net X-Www: https://mistral.enst.fr/~pioch/ X-Pgp-Key: "finger -l pioch@inf.enst.fr | pgp -fka" X-Domestic-Intelligence: SDI radar NSA FtBragg DES crypt Peking spy DST Kennedy X-Nap: A nuclear war can ruin your whole day. X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 698 Suggestion: GIF89a with transparent background often have a #c0c0c0 (grey75) color, so that clients which don't support transparent GIF89a background extension blocks display them the same color as the root color (grey75 usually). BUT, when printing such a page, the GIF89a "grey" transparent background should be mapped to *white*, since it's invisible! Mosaic/X11, etc. keep the real original color when printing (dithering grey or whatever) just ignoring the transparent attribute. Chimera just prints it as it's displayed (substituting the background color). Any idea on how to map that to white while printing? Let me know if I'm not clear enough and I'll try to rephrase it. - -- Nicolas ------- Message 16 Received: from duke.cs.duke.edu by JIMI.CS.UNLV.EDU id aa13242; 6 Oct 94 16:13 PDT Received: from wolves.UUCP by duke.cs.duke.edu (5.65/3.10G/4.1.3) id AA06305; Thu, 6 Oct 94 19:13:31 -0400 Received: from deepthot by wolves.durham.nc.us with uucp (Linux Smail3.1.28.1 #5) id m0qt1Wg-0000X7C; Thu, 6 Oct 94 18:43 EDT Date: Thu, 6 Oct 1994 18:10:26 -0400 (EDT) From: Jay Denebeim <denebeim@deepthot.cary.nc.us> To: cs.unlv.edu!bug-chimera@deepthot.cary.nc.us Subject: Unsubscribe Message-Id: <Pine.LNX.3.90.941006181008.328A-100000@deepthot.cary.nc.us> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Unsubscribe Sig under construction Jay Denebeim jay@deepthot.cary.nc.us denebeim@deepthot.cary.nc.us denebeim@deepthot.cybernetics.net duke!wolves!deepthot!denebeim ------- Message 17 Received: from magic-sam.CS.UNLV.EDU by JIMI.CS.UNLV.EDU id aa05263; 7 Oct 94 1:39 PDT To: bug-chimera@cs.unlv.edu Subject: Re: Forms fixes Date: Fri, 07 Oct 1994 01:39:22 -0700 From: Jay Nietling <jay@magic-sam.CS.UNLV.EDU> - ------- Forwarded Message Received: from telion.radio-msu.net by JIMI.CS.UNLV.EDU id aa00425; 7 Oct 94 0:09 PDT Received: from nsrd.npi.msu.su (nsrd.npi.msu.su [158.250.2.43]) by telion.radio-msu.net (8.6.9/8.6.9) with SMTP id KAA10310 for <bug-chimera-request@JIMI.CS.UNLV.EDU>; Fri, 7 Oct 1994 10:08:56 +0300 Received: by nsrd.npi.msu.su id AA00299; Fri, 7 Oct 1994 10:04:48 +0400 Date: Fri, 7 Oct 1994 10:04:48 +0400 From: "Mileev Valery N." <mileev@nsrd.npi.msu.su> Message-Id: <199410070604.AA00299@nsrd.npi.msu.su> To: bug-chimera-request@JIMI.CS.UNLV.EDU Subject: Re: Forms fixes Some practical comments from RUSSIA. At RUSSIAN WWW 8-bits KOI-8 coding are used traditionally (not ISOCyr1 or others). It is work well in Chimera and Mosaic for common HTML documents. Unfortunately, this works not properly in FORM REQUEST fields. I think, It is coming both from browser and cgi-bin tools. This defect restricts our possibilities to produce Cyrillic (RUSSIAN) Request form in WWW. I am glad to hear some consulting words on that score. Valery Mileev Institute of Nuclear Physics Moscow State University MOSCOW RUSSIA mileev@npi.msu.su - ------- End of Forwarded Message ------- Message 18 Received: from nic.lth.se by JIMI.CS.UNLV.EDU id aa06784; 7 Oct 94 2:41 PDT Received: from gatekeeper.axis.se by mail.lth.se with smtp (Smail3.1.28.1 #2) id m0qtBnN-000MUKC; Fri, 7 Oct 94 10:40 MET Received: from axisab.axis.se by gatekeeper.axis.se with smtp (Smail3.1.28.1 #20) id m0qtBnK-000trKC; Fri, 7 Oct 94 10:40 GMT-1:00 Received: from axis.se by axisab.axis.se with smtp (Smail3.1.28.1 #1) id m0qtBnG-000pgGC; Fri, 7 Oct 94 10:40 MET Message-Id: <m0qtBnG-000pgGC@axisab.axis.se> To: bug-chimera@cs.unlv.edu Subject: 1.60 + Sunos5.3 + X11R6p5? Has anyone done it? X-Face: ";qfS@AVy6@.5R{>2LcAxmyV?RZ~3m^^du$]?z-ay|Oy,;y_ ( &j}Rlxyd}.[< cfx7Fu-c;Mk:_tYRh! ) \:nB}b/`/eq'td^-efI\>:@m0` ( BL/:H5NU]|MFw`* %R%$Vk+4_-h];!_wh ) sPEg|KeGbQN9xY2i7jg/0<6;lmw"IIN9TWn0+>|}J.S KMh9gO$Aa`@U~s<MHLv&Wa``g%Iv MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 07 Oct 1994 10:40:49 MET From: Joergen Haegg <jh@axis.se> I would like to know if there is anyone that has got 1.60 to work in Sunos5.3 (solaris2.3 :-) with X11R6. I've compiled it with gcc 2.5.8, and the problem is that it is extremely slow. When I start it, is says '8 bytes out of 8 loaded'. After 10-15 seconds it says '920 bytes loaded' (That's the size of the homepage.). And then nothing happens. A trace shows that chimera does a ioctl and a poll every second, and sometimes a write. (Se below) 1.60 works fine in Sunos4.1.3 with X11R6, no problem. By the way, xc17 didn't have this problem. - --------------------------------------------- ioctl(5, FIONREAD, 0xEFFFE48C) =3D 0 poll(0xEFFFCE80, 1, 1000) =3D 0 ioctl(5, FIONREAD, 0xEFFFE48C) =3D 0 poll(0xEFFFCE80, 1, 1000) =3D 0 ioctl(5, FIONREAD, 0xEFFFE48C) =3D 0 poll(0xEFFFCE80, 1, 1000) =3D 0 ioctl(5, FIONREAD, 0xEFFFE48C) =3D 0 poll(0xEFFFCE80, 1, 1000) =3D 0 write(5, " =3D\0\0040780\0 M\0\0\0\0".., 80) =3D 80 ioctl(5, FIONREAD, 0xEFFFE48C) =3D 0 poll(0xEFFFCE80, 1, 1000) =3D 0 ioctl(5, FIONREAD, 0xEFFFE48C) =3D 0 poll(0xEFFFCE80, 1, 1000) =3D 0 ioctl(5, FIONREAD, 0xEFFFE48C) =3D 0 poll(0xEFFFCE80, 1, 1000) =3D 0 ioctl(5, FIONREAD, 0xEFFFE48C) =3D 0 ------- Message 19 Received: from cephas.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa11246; 7 Oct 94 4:57 PDT To: Joergen Haegg <jh@axis.se> cc: bug-chimera@cs.unlv.edu Subject: Re: 1.60 + Sunos5.3 + X11R6p5? Has anyone done it? In-reply-to: Your message of "Fri, 07 Oct 1994 10:40:49 +0700." <m0qtBnG-000pgGC@axisab.axis.se> Date: Fri, 07 Oct 1994 04:56:55 -0700 From: John Kilburg <john@cephas.ISRI.UNLV.EDU> Actually, tonight I used a friend's account to try chimera out on a Solaris 2.x machine after I read your last report but it never actually made it to the screen (the machine is slow and 100ms away on the net...). I am doing some questionable things (select() on a regular file) to eliminate duplicate code that may cause problems. I'll do something about it in 1.61. At the current release rate that will the 4th quarter of 1997 :) -john > >I would like to know if there is anyone that has got 1.60 >to work in Sunos5.3 (solaris2.3 :-) with X11R6. > >I've compiled it with gcc 2.5.8, and the problem is that it >is extremely slow. >When I start it, is says '8 bytes out of 8 loaded'. >After 10-15 seconds it says '920 bytes loaded' (That's the size >of the homepage.). >And then nothing happens. >A trace shows that chimera does a ioctl and a poll every second, and >sometimes a write. (Se below) > >1.60 works fine in Sunos4.1.3 with X11R6, no problem. > >By the way, xc17 didn't have this problem. > >--------------------------------------------- > >ioctl(5, FIONREAD, 0xEFFFE48C) =3D 0 >poll(0xEFFFCE80, 1, 1000) =3D 0 >ioctl(5, FIONREAD, 0xEFFFE48C) =3D 0 >poll(0xEFFFCE80, 1, 1000) =3D 0 >ioctl(5, FIONREAD, 0xEFFFE48C) =3D 0 >poll(0xEFFFCE80, 1, 1000) =3D 0 >ioctl(5, FIONREAD, 0xEFFFE48C) =3D 0 >poll(0xEFFFCE80, 1, 1000) =3D 0 >write(5, " =3D\0\0040780\0 M\0\0\0\0".., 80) =3D 80 >ioctl(5, FIONREAD, 0xEFFFE48C) =3D 0 >poll(0xEFFFCE80, 1, 1000) =3D 0 >ioctl(5, FIONREAD, 0xEFFFE48C) =3D 0 >poll(0xEFFFCE80, 1, 1000) =3D 0 >ioctl(5, FIONREAD, 0xEFFFE48C) =3D 0 >poll(0xEFFFCE80, 1, 1000) =3D 0 >ioctl(5, FIONREAD, 0xEFFFE48C) =3D 0 > ------- Message 20 Received: from citi.umich.edu by JIMI.CS.UNLV.EDU id aa12994; 7 Oct 94 6:13 PDT Received: from citi.umich.edu by citi.umich.edu for john@cephas.ISRI.UNLV.EDU bug-chimera@cs.unlv.edu with SMTP; Fri, 07 Oct 94 09:11:59 -0400 From: Jim.Rees@umich.edu To: John Kilburg <john@cephas.ISRI.UNLV.EDU> Cc: bug-chimera@cs.unlv.edu Date: Fri, 07 Oct 94 09:11:51 EDT Subject: Re: 1.60 + Sunos5.3 + X11R6p5? Has anyone done it? Sender: rees@citi.umich.edu In-Reply-To: John Kilburg, Fri, 07 Oct 94 04:56:55 PDT I am doing some questionable things (select() on a regular file) I don't think that's questionable (even thought I'm the one who questioned it). It should work as long as you're not running afs on an apollo. The poll/ioctl loop on Solaris is normal. That's the select timing out (or returning) once a second. However, there is at least one potential problem. If your stdio buffer size is bigger than BUFSIZ, the first fread will fill the buffer but only return part of it. Select will then fail, since there is nothing more to read from the fd, but there is still data in the stdio buffer, which will be missed. This could account for the truncated pages and missing inline images. The stdio buffer can be bigger than BUFSIZ because some versions of stdio use statb->st_blocksize instead. It's usually not easy to mix stdio and select, but it can be done if you're careful. The right way to do the cancel button, if I may be somewhat critical here, is not the way you're doing it at all. What you want to do is use XtAppAddInput. That requires turning the code inside out (literally!) but should work much better. Actually, the way ReadInput is written, and the fact that everything uses it, should make it not too hard. I'll try it myself later today and see. By the way, I hate it when people cast 0 instead of using NULL. NULL is defined as 0, always, and never needs to be cast. Look it up if you don't believe me. ------- Message 21 Received: from citi.umich.edu by JIMI.CS.UNLV.EDU id aa04583; 7 Oct 94 14:27 PDT Received: from [141.211.128.188] by citi.umich.edu for mileev@nsrd.npi.msu.su bug-chimera@cs.unlv.edu with SMTP; Fri, 07 Oct 94 17:26:55 -0400 From: Jim.Rees@umich.edu To: "Mileev Valery N." <mileev@nsrd.npi.msu.su> Cc: bug-chimera@cs.unlv.edu Date: Fri, 07 Oct 1994 17:26:53 -0400 Subject: Re: Forms fixes Sender: rees@citi.umich.edu In-Reply-To: Jay Nietling, Fri, 07 Oct 1994 01:39:22 PDT At RUSSIAN WWW 8-bits KOI-8 coding are used traditionally (not ISOCyr1 or others). You'll probably want J.D.'s patch to EscapeURL(). Just change all the local char variables to unsigned char. I hope you're putting the right mime headers on your html files. I don't know what the official header would be, something like this: Content-type: text/html; charset=koi8 Some day, all browsers will watch the character set, but right now I don't think any of them do. Maybe John will add this to chimera for us. It actually wouldn't be that hard (he says, not having looked at it). Last time I looked, I didn't see any good way in httpd to specify the character set of a document. But I haven't looked into it closely. Can you give me the url of a koi8 document so I can experiment? ------- Message 22 Received: from citi.umich.edu by JIMI.CS.UNLV.EDU id aa18615; 10 Oct 94 10:06 PDT Received: from [141.211.128.188] by citi.umich.edu for bug-chimera@cs.unlv.edu with SMTP; Mon, 10 Oct 94 12:43:12 -0400 From: Jim.Rees@umich.edu To: bug-chimera@cs.unlv.edu Date: Mon, 10 Oct 1994 12:43:11 -0400 Subject: failed inline images Sender: rees@citi.umich.edu I've tracked down at least one reason why inline images sometimes fail to load. If it's a small image, less than the stdio buffer size, then the entire image will have been read into the stdio buffer before ReadInput is called. The select() fails, since there is nothing more to read. I don't see the sense in using select in ReadInput, so I just tore it out, and it seems to have fixed the problem for me. I still sometimes get truncated inline images, and I'm tracking that down now. Here's a patch to input.c for chimera 1.60: *** input.c- Fri Sep 30 04:37:18 1994 - --- input.c Mon Oct 10 12:01:34 1994 *************** *** 81,143 **** int blen = 0; int tlen = 0; int btlen = 0; - - int rval; int barp; char buffer[BUFSIZ]; char *t = NULL; - - fd_set readfds; - - struct timeval to; int readlen; - - int s = fileno(fp); for (readlen = max; max == 0 || readlen > 0; readlen -= blen) { ! FD_ZERO(&readfds); ! FD_SET(s, &readfds); ! to.tv_sec = 1; ! to.tv_usec = 0; ! ! if ((rval = select(s + 1, &readfds, (fd_set *)0, (fd_set *)0, &to)) > 0) { ! if (FD_ISSET(s, &readfds)) { ! if (linemode) { ! char *b; ! ! if ((b = fgets(buffer, sizeof(buffer), fp)) != NULL) ! { ! t = alloc_string(b); ! tlen = strlen(t); ! if (t[tlen - 2] == '\r') ! { ! tlen -= 2; ! t[tlen] = '\0'; ! } ! else if (t[tlen - 1] == '\n') ! { ! t[--tlen] = '\0'; ! } ! } ! break; } ! else { ! barp = (readlen > sizeof(buffer) || max == 0 ! ? sizeof(buffer):readlen); ! blen = fread(buffer, 1, barp, fp); ! if (blen <= 0) break; ! tlen += blen; ! if (t) t = (char *)realloc_mem(t, tlen + 1); ! else t = (char *)alloc_mem(tlen + 1); ! memcpy(t + btlen, buffer, blen); ! btlen = tlen; } } } ! else if (rval < 0) { ! break; } if (DisplayTransferStatus(tlen, max) == 1) - --- 81,124 ---- int blen = 0; int tlen = 0; int btlen = 0; int barp; char buffer[BUFSIZ]; char *t = NULL; int readlen; for (readlen = max; max == 0 || readlen > 0; readlen -= blen) { ! if (linemode) { ! char *b; ! ! if ((b = fgets(buffer, sizeof(buffer), fp)) != NULL) { ! t = alloc_string(b); ! tlen = strlen(t); ! if (t[tlen - 2] == '\r') { ! tlen -= 2; ! t[tlen] = '\0'; } ! else if (t[tlen - 1] == '\n') { ! t[--tlen] = '\0'; } } + break; } ! else { ! barp = (readlen > sizeof(buffer) || max == 0 ! ? sizeof(buffer):readlen); ! blen = fread(buffer, 1, barp, fp); ! if (blen <= 0) break; ! tlen += blen; ! if (t) t = (char *)realloc_mem(t, tlen + 1); ! else t = (char *)alloc_mem(tlen + 1); ! memcpy(t + btlen, buffer, blen); ! btlen = tlen; } if (DisplayTransferStatus(tlen, max) == 1) ------- Message 23 Received: from ns.bbc.co.uk by JIMI.CS.UNLV.EDU id aa29896; 19 Oct 94 7:04 PDT Received: from ant.rd.eng.bbc.co.uk (rdmailgate.rd.eng.bbc.co.uk) by ns.bbc.co.uk with SMTP id AA18130 (5.65c/IDA-1.4.4 for <bug-chimera%charles.CS.UNLV.EDU@mail.rd.bbc.co.uk>); Wed, 19 Oct 1994 15:03:44 +0100 From: Rob May <robert.may@rd.eng.bbc.co.uk> Message-Id: <17755.9410191403@ant.rd.eng.bbc.co.uk> Subject: access_nntp and external protocols To: Chimera Bugs <bug-chimera@charles.CS.UNLV.EDU> Date: Wed, 19 Oct 1994 15:03:42 +0100 (BST) X-Phone: +44 737 836535 (Direct line). +44 737 832361 (Switchboard). X-Fax: +44 737 832336 X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 4056 I've just got back from a few weeks away, and have only just got chimera 1.60. I compiled in with no problems (gcc 2.6.0, X11R4, SunOS 4.1B). The only thing that I've found that doesn't work any more is the access_nntp code, as the data piped into the external protocol commands has been changed from 1.5.*. (See the help page for a description of what the data now looks like -- a standard HTTP request). Here's a patch that makes it work. (It's a hack, and really need doing properly) : - --- cut here --- *** ../../chimera-1.60/util/access_nntp Thu Sep 15 03:53:32 1994 - --- access_nntp Wed Oct 19 14:55:53 1994 *************** *** 111,119 **** sub ProcessHTTPRequest { ! # format of input # ! # HTTP blah # URI: nntp://host/newsgroup/article# # X-protocol: nntp # X-hostname: host - --- 111,121 ---- sub ProcessHTTPRequest { ! # format of input - headers may be in any order, or not present or blank # ! # BLAH URI HTTP/1.0 ! # User-Agent: chimera/1.60 ! # Accept: *.* # URI: nntp://host/newsgroup/article# # X-protocol: nntp # X-hostname: host *************** *** 125,133 **** chop ($http = <STDIN>); ! ($http_id, $http_code, $http_string) = split (/\s+/, $http, 3); - - ($http_name, $http_version) = split (/\//, $http_id); if ($http_name ne "HTTP") { - --- 127,134 ---- chop ($http = <STDIN>); ! ($http_cmd, $http_uri, $http_id) = split (/\s+/, $http, 3); ($http_name, $http_version) = split (/\//, $http_id); if ($http_name ne "HTTP") { *************** *** 142,160 **** # check HTTP codes here # ! if ($http_code < 200 || $http_code >= 300) { - - &HTTPError ("HTTP error: $http_code $http_string\n"); - - } ! chop ($uri = <STDIN>); - - ($uri_name, $uri_proto, $uri_path) = split (/\s*:\s*/, $uri); - - # maybe check that the $uri_name is "URI"? # (is there some guaranteed order to the http info?) - --- 143,161 ---- # check HTTP codes here # ! #if ($http_code < 200 || $http_code >= 300) { ! # ! #&HTTPError ("HTTP error: $http_code $http_string\n"); ! #} + #chop ($uri = <STDIN>); ! #($uri_name, $uri_proto, $uri_path) = split (/\s*:\s*/, $uri); # maybe check that the $uri_name is "URI"? # (is there some guaranteed order to the http info?) *************** *** 196,201 **** - --- 197,213 ---- $hostname = $type_value; } + elsif ($type_name eq "URI") { + + ($uri_proto, $uri_path) = split (/\s*:\s*/, $type_value); + + if ($uri_proto ne "nntp") { + + &HTTPError ("protocal \"$uri_proto\" not accepted for URIs\n"); + } + + } + elsif ($type_name eq "X-port") { next if ($type_value eq "0"); *************** *** 222,229 **** } ! print STDERR "HTTP\tcode:$http_code\tstring:$http_string\n" ! if (defined $DEBUG); print STDERR "URI\tprotocol:$uri_proto\tpath:$uri_path\n" if (defined $DEBUG); - --- 234,241 ---- } ! #print STDERR "HTTP\tcode:$http_code\tstring:$http_string\n" ! #if (defined $DEBUG); print STDERR "URI\tprotocol:$uri_proto\tpath:$uri_path\n" if (defined $DEBUG); *************** *** 253,266 **** if (defined $DEBUG); } ! if (defined @unknown_fields) { ! foreach $f (@unknown_fields) { ! print STDERR "unknown attribute: \"$f\"\n" ! if ($f ne ""); ! } ! } if (defined $MESSAGE) { - --- 265,279 ---- if (defined $DEBUG); } ! #Don't print all the fields that we don't recognise -- we expect quite a lot ! #if (defined @unknown_fields) { ! #foreach $f (@unknown_fields) { ! #print STDERR "unknown attribute: \"$f\"\n" ! #if ($f ne ""); ! #} ! #} if (defined $MESSAGE) { - --- cut here --- Rob. - --------------------------------------------------------------------------- - --- Robert May. e-mail: robert.may@rd.eng.bbc.co.uk Tel: +44 737 836535 --- - -- You may post, repost or publish *ANY* communication received from me -- - --------------------------------------------------------------------------- ------- Message 24 Received: from ra.ibr.cs.tu-bs.de by JIMI.CS.UNLV.EDU id aa05775; 19 Oct 94 9:49 PDT Received: from moocow.math.nat.tu-bs.de by ra.ibr.cs.tu-bs.de (5.65/1.341) id AA12049; Wed, 19 Oct 94 17:49:03 +0100 Received: by moocow (Linux Smail3.1.28.1 #4) id m0qxeDu-00017yC; Wed, 19 Oct 94 17:50 MET Message-Id: <m0qxeDu-00017yC@moocow> Date: Wed, 19 Oct 94 17:50 MET From: Mike Dowling <mike@moocow.math.nat.tu-bs.de> To: bug-chimera@cs.unlv.edu Subject: chimera and pretty pictures Reply-To: on.dowling@zib-berlin.de X-Attribution: M. Dowling I cannot believe that this is a bug; I'm obviously doing something wrong. I cannot get chimera to produce any graphics (linux 1.1.54, X11R6). I just get a cross where the graphic is supposed to be. I'm sure this must be the most frequently asked question of all, but how does one turn on graphics? Chimera is otherwise makes a very good impression. I never liked Mosaic which I consider a DOSsy monstrosity that doesn't have any UNIX feel about it at all. Chimera in contrast is intuitive to use and is a proper X11 program. It's a pity that there isn't a man page to be seen, though. Mike Dowling ------- Message 25 Received: from tel13.tel.vtt.fi by JIMI.CS.UNLV.EDU id aa16015; 19 Oct 94 13:14 PDT Received: by tel13.tel.vtt.fi id AA10117 (5.65c/IDA-1.4.4 for bug-chimera@cs.unlv.edu); Wed, 19 Oct 1994 22:12:50 +0200 Date: Wed, 19 Oct 1994 22:12:50 +0200 From: Markku Savela <savela@tel.vtt.fi> Message-Id: <199410192012.AA10117@tel13.tel.vtt.fi> To: bug-chimera@cs.unlv.edu Cc: on.dowling@zib-berlin.de In-Reply-To: Mike Dowling's message of Wed, 19 Oct 94 17:50 MET <m0qxeDu-00017yC@moocow> Subject: chimera and pretty pictures Reply-To: Markku Savela <savela@tel.vtt.fi> >I cannot believe that this is a bug; I'm obviously doing something >wrong. I cannot get chimera to produce any graphics (linux 1.1.54, >X11R6). I just get a cross where the graphic is supposed to be. I'm >sure this must be the most frequently asked question of all, but how >does one turn on graphics? Hmm.. this is exactly what I get with SunOS 4.1.3 + gcc + X11R6. I assumed it just couldn't find the chimera_giftoppm or something (configuration error). Haven't really looked into it. If someone points you to exact problem point, mail a copy to me. Also, I get immediate core dump when I try view source option ... (again I assume my config is somehow messed up, it was a very quick hack and go compilation). - -- markku savela ------- Message 26 Received: from cephas.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa18956; 19 Oct 94 14:38 PDT To: Rob May <robert.may@rd.eng.bbc.co.uk> cc: Chimera Bugs <bug-chimera@charles.cs.unlv.edu> Subject: Re: access_nntp and external protocols In-reply-to: Your message of "Wed, 19 Oct 1994 15:03:42 BST." <17755.9410191403@ant.rd.eng.bbc.co.uk> Date: Wed, 19 Oct 1994 14:38:45 -0700 From: John Kilburg <john@cephas.ISRI.UNLV.EDU> >I've just got back from a few weeks away, and have only just got chimera >1.60. I compiled in with no problems (gcc 2.6.0, X11R4, SunOS 4.1B). > >The only thing that I've found that doesn't work any more is the >access_nntp code, as the data piped into the external protocol commands >has been changed from 1.5.*. (See the help page for a description of >what the data now looks like -- a standard HTTP request). Yeah, I made the change but didn't put the correct access_nntp into the distribution. Thanks for the patch. -john ------- Message 27 Received: from cephas.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa20592; 19 Oct 94 14:46 PDT To: on.dowling@zib-berlin.de cc: bug-chimera@cs.unlv.edu Subject: Re: chimera and pretty pictures In-reply-to: Your message of "Wed, 19 Oct 1994 17:50:00 +0700." <m0qxeDu-00017yC@moocow> Date: Wed, 19 Oct 1994 14:46:42 -0700 From: John Kilburg <john@cephas.ISRI.UNLV.EDU> >I cannot believe that this is a bug; I'm obviously doing something wrong. I >cannot get chimera to produce any graphics (linux 1.1.54, X11R6). I just get >a >cross where the graphic is supposed to be. I'm sure this must be the most >frequently asked question of all, but how does one turn on graphics? You will need to grab the netpbm utilities. Make sure that you make a link called giftoppm to giftopnm. Also, make sure that the netpbm utilities are in your path or in the path specified with the X resource Chimera.path. Also, make sure that chimera knows where the convert file is located. >Chimera is otherwise makes a very good impression. I never liked Mosaic which >I consider a DOSsy monstrosity that doesn't have any UNIX feel about it at all . >Chimera in contrast is intuitive to use and is a proper X11 program. It's a >pity that there isn't a man page to be seen, though. Thanks. There used to be a manual page but it got so hoplessly outdated that I gave up on it. -john ------- Message 28 Received: from lust.mrrl.lut.ac.uk by JIMI.CS.UNLV.EDU id aa22346; 19 Oct 94 15:35 PDT Received: from localhost (martin@localhost) by lust.mrrl.lut.ac.uk (8.6.9/8.6.9) with SMTP id XAA29995 for <bug-chimera@cs.unlv.edu>; Wed, 19 Oct 1994 23:35:28 +0100 Message-Id: <199410192235.XAA29995@lust.mrrl.lut.ac.uk> To: bug-chimera@cs.unlv.edu Subject: URN lookup via proxy X-Mailer: exmh version 1.5omega 10/6/94 Date: Wed, 19 Oct 1994 23:35:27 +0100 From: Martin Hamilton <martin@mrrl.lut.ac.uk> Hi, I've been playing around with some toy implementations of the URN resolution scheme described in <URL:https://www.path.net/mitra/urn.html >, and noticed that Chimera rejects the "urn:" scheme out of hand It would be useful if Chimera were capable of understanding URNs to the point of knowing to pass them on to a proxy server when the urn_proxy environmental variable is set - is anyone working on this ? Cheers, Martin ------- Message 29 Received: from cephas.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa26102; 19 Oct 94 17:07 PDT To: Martin Hamilton <martin@mrrl.lut.ac.uk> cc: bug-chimera@cs.unlv.edu Subject: Re: URN lookup via proxy In-reply-to: Your message of "Wed, 19 Oct 1994 23:35:27 BST." <199410192235.XAA29995@lust.mrrl.lut.ac.uk> Date: Wed, 19 Oct 1994 17:06:49 -0700 From: John Kilburg <john@cephas.ISRI.UNLV.EDU> >I've been playing around with some toy implementations of the URN >resolution scheme described in <URL:https://www.path.net/mitra/urn.html >>, and noticed that Chimera rejects the "urn:" scheme out of hand > >It would be useful if Chimera were capable of understanding URNs to >the point of knowing to pass them on to a proxy server when the >urn_proxy environmental variable is set - is anyone working on this ? I haven't worked on it at all. I'll try to take a look but I've been busy and lazy lately so it won't happen real soon. Here is an email I received a long time back for what, I think, is a pretty cool feature. The patch is for a pretty old version of chimera but I'm sure most of the code will just drop in. I thought that you might be interested in it. Replied: Wed, 25 May 1994 23:28:28 -0700 Replied: Theodore Ts'o <tytso@athena.mit.edu> Received: from TSX-11.MIT.EDU by JIMI.CS.UNLV.EDU id aa11900; 11 Mar 94 22:26 PST Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA28982; Sat, 12 Mar 94 01:25:58 EST Date: Sat, 12 Mar 94 01:25:58 EST From: Theodore Ts'o <tytso@ATHENA.MIT.EDU> Message-Id: <9403120625.AA28982@tsx-11.MIT.EDU> To: john@cs.unlv.edu Subject: Thanks for chimera..... and a code donation.... Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Hi! I just wanted to thank you putting chimera together --- and I've got a code donation for you to consider. Basically, it's a URL translator. I got tired of waiting for URN's or URC's, or ORI's, or whatever today's favorite acronym is. :-) So, I threw together the following code; basically it matches a URL against a regular expression, and if it finds a match, it uses a substitution rule to figure out how to rewrite the URL. As example, take the following transformation rule: https://www.mit.edu:8001/afs/(.*) file:/afs/\1 It translates URL's such as: https://www.mit.edu:8001/afs/athena/user/tytso/html/home_page.html to: file:/afs/athena/user/tytso/html/home_page.html By using just this transformation, I was able to speed up loading a user's home page by a factor of 750%. Of course, if you want to dereference links which were made by careless users at MIT, that use "file:/afs/athena/xxx", and you don't have AFS you can use the exact opposite transformation to get those URL's translated back into a http form that queries a AFS gateway: file:/afs/athena/(.*) http::/www.mit.edu:8001/afs/athena/\1 This is also useful if you know that some site mirrors some busy overused WWW server; you can use a regular expression transformation to bypass the busy site. Anyway, enough sales pitch. First, I'll send you the patch which this hooks into, and then the actual file. The routine requires a POSIX regular expression library; I'm currently using the GNU regex library, which has worked just fine for me. Let me know what you think! - Ted ** document.c 1994/03/07 16:35:11 1.1 - --- document.c 1994/03/07 21:35:18 *************** *** 200,212 **** char ext[256]; int portno; unsigned long flags; portno = -1; access[0] = '\0'; hostname[0] = '\0'; filename[0] = '\0'; ext[0] = '\0'; ! flags = ParseURL(url, access, sizeof(access), hostname, sizeof(hostname), &portno, - --- 200,213 ---- char ext[256]; int portno; unsigned long flags; + extern char *url_translate(); portno = -1; access[0] = '\0'; hostname[0] = '\0'; filename[0] = '\0'; ext[0] = '\0'; ! flags = ParseURL(url_translate(url), access, sizeof(access), hostname, sizeof(hostname), &portno, - ------------------------------------------------------------------ /* * url_translate.c --- do URL transmogrifications using regular * expresson matching and replacing * * Copyright 1994 by Theodore Ts'o <tytso@athena.mit.edu> * * This file may be distributed under the terms of the GNU Public License. */ #include <stdio.h> #include <unistd.h> #include <stdlib.h> #include <sys/types.h> #include <string.h> #include <pwd.h> #include "regex.h" #define LOCAL_TRANSLATION_FILE ".url_translations" #define TRANSLATION_FILE "/usr/local/lib/url_translations" struct translate_pat { char *match; char *replace; struct translate_pat *next; }; struct translate_pat *patterns = NULL; static int initialized = 0; static int match_replace(char *regex, char *input, char *replace, char *output, int maxsize) { regex_t re; int retval; regmatch_t *pmatch; int i; int match; char *p = replace, *q; int size = maxsize-1; retval = regcomp(&re, regex, REG_EXTENDED); if (retval) return -1; pmatch = malloc(sizeof(regmatch_t) * 10); retval = regexec(&re, input, 10, pmatch, 0); if (retval == REG_NOMATCH) return 0; if (retval) return -1; for(p = replace, q=output; *p; p++) { if (*p == '\\' && *(p+1) >= '0' && *(p+1) <= '9') { p++; match = *p - '0'; for (i = pmatch[match].rm_so; i < pmatch[match].rm_eo; i++) { *q++ = input[i]; if (!--size) goto finish; } } else { *q++ = *p; if (!--size) goto finish; } } finish: regfree(&re); *q = '\0'; return 1; } static char *strdup(char *s) { char *r; r = malloc(strlen(s)+1); if (!r) return NULL; strcpy(r, s); return r; } static void read_translation_patterns(char *filename, FILE *f) { char buf[1024]; char *s; struct translate_pat *pat; struct translate_pat *last; if (!f) f = fopen(filename, "r"); if (!f) return; #ifdef DEBUG if (filename) printf("Reading in translation file %s....\n", filename); #endif for (last = patterns; last && last->next; last = last->next); while (!feof(f)) { if (!fgets(buf, sizeof(buf), f)) break; if (buf[0] == '#') continue; s = strchr(buf, '\n'); *s = '\0'; s = strchr(buf, '\t'); *s = '\0'; pat = malloc(sizeof(struct translate_pat)); pat->match = strdup(buf); pat->replace= strdup(s+1); pat->next = 0; if (last) last->next = pat; else patterns = pat; last = pat; } } void initialize_url_translations() { FILE *f; struct passwd *pwd; char filename[1024]; pwd = getpwuid(getuid()); if (pwd) { sprintf(filename, "%s/%s", pwd->pw_dir, LOCAL_TRANSLATION_FILE); read_translation_patterns(filename, NULL); } read_translation_patterns(TRANSLATION_FILE, NULL); initialized++; } char *url_translate(char *url) { struct translate_pat *p; static char buf[1024]; int retval; if (!initialized) initialize_url_translations(); for (p = patterns; p; p = p->next) { retval = match_replace(p->match, url, p->replace, buf, sizeof(buf)); if (retval == 1) { #ifdef DEBUG printf("'%s' translated to '%s'\n", url, buf); #endif return buf; } } return url; } #if 0 main(int argc, char **argv) { int retval; char buff[1024]; printf("%s\n", url_translate(argv[1])); exit(0); } #endif ------- Message 30 Received: from tango.rahul.net by JIMI.CS.UNLV.EDU id aa29241; 19 Oct 94 18:38 PDT Received: from dandelion.com by tango.rahul.net with SMTP id AA11836 (5.67b8/IDA-1.5 for <bug-chimera@cs.unlv.edu>); Wed, 19 Oct 1994 18:38:31 -0700 Received: (from lnz@localhost) by dandelion.com (8.6.9/8.6.9) id SAA01498; Wed, 19 Oct 1994 18:38:30 -0700 Date: Wed, 19 Oct 1994 18:38:30 -0700 From: "Leonard N. Zubkoff" <lnz@dandelion.com> Message-Id: <199410200138.SAA01498@dandelion.com> To: bug-chimera@cs.unlv.edu Subject: Display Bug I am seeing a problem with Chimera's display of the following HTML: <address> Leonard N. Zubkoff<br> Dandelion Digital<br> lnz@dandelion.com<br> </address> If the <address> </address> are not present, then everything looks fine. With the <address> tags the upper right portion of the final "f" and "l" are missing. Leonard ------- Message 31 Received: from fxwidegw.fujixerox.co.jp by JIMI.CS.UNLV.EDU id aa03039; 19 Oct 94 20:25 PDT Received: from fxmxgw.fujixerox.co.jp (root@fxmxgw.fujixerox.co.jp [129.249.88.3]) by fxwidegw.fujixerox.co.jp (8.6.9+2.4Wb/3.3Wb-05/06/94-1.9) with ESMTP id MAA06932 for <bug-chimera@cs.unlv.edu>; Thu, 20 Oct 1994 12:25:19 +0900 Received: from fox.fax.iwa.fujixerox.co.jp (root@[129.249.196.167]) by fxmxgw.fujixerox.co.jp (8.6.9+2.4Wb/3.1W-02/17/94-fxmxgw/1.7) with ESMTP id MAA19196 for <bug-chimera@cs.unlv.edu>; Thu, 20 Oct 1994 12:25:17 +0900 Received: (from jun@localhost) by fox.fax.iwa.fujixerox.co.jp (8.6.9/3.3W-94082612) id MAA15589; Thu, 20 Oct 1994 12:25:14 +0900 Date: Thu, 20 Oct 1994 12:25:14 +0900 From: Junichi Kurokawa <jun@fox.fax.iwa.fujixerox.co.jp> Message-Id: <199410200325.MAA15589@fox.fax.iwa.fujixerox.co.jp> To: bug-chimera@cs.unlv.edu Subject: [chimera-1.60] possible bugs, "source" and gifs To whom it may concern; Chimera-1.60 compiled and ran successfully on the following environment. However, a few minor bugs(?) has been observed in that release. My apology in advance if these have already been reported, or not really bugs. * Chimera-1.60.tar.gz (1.60 prerelease 18-real release) * XFree86-2.1.1, stock gcc-2.4.5, Gnu make, FreeBSD-1.1.5.1 (1) pressing "source" button only gives a halfway output of the html. Try the `Chimera Home Page' by 1.60, I think it will reproduce. (2) Some gif images are slightly garbled. Thanks to the cache, displaying the cached images by xv did give clean outcomes. Disabling `chimera-giftoppm' did not change the symptom. The latter problem may need more tracking down, though. I hope this helps a bit. Thank you. Regards, junichi - -- Junichi Kurokawa Image and Printing System Products Development Center Fuji Xerox Co., Ltd. ------- Message 32 Received: from citi.umich.edu by JIMI.CS.UNLV.EDU id aa20311; 20 Oct 94 5:08 PDT Received: from citi.umich.edu by citi.umich.edu for jun@fox.fax.iwa.fujixerox.co.jp bug-chimera@cs.unlv.edu with SMTP; Thu, 20 Oct 94 08:07:21 -0400 From: Jim.Rees@umich.edu To: Junichi Kurokawa <jun@fox.fax.iwa.fujixerox.co.jp> Cc: bug-chimera@cs.unlv.edu Date: Thu, 20 Oct 94 08:07:13 EDT Subject: Re: [chimera-1.60] possible bugs, "source" and gifs Sender: rees@citi.umich.edu In-Reply-To: Junichi Kurokawa, Thu, 20 Oct 94 12:25:14 +0900 (1) pressing "source" button only gives a halfway output of the html. Try the `Chimera Home Page' by 1.60, I think it will reproduce. (2) Some gif images are slightly garbled. These sound like the select() bug I reported earlier. Please try this patch and let me know if it fixes the bug for you. % diff -cb input.c- input.c *** input.c- Fri Sep 30 04:37:18 1994 - --- input.c Mon Oct 10 12:01:34 1994 *************** *** 81,106 **** int blen = 0; int tlen = 0; int btlen = 0; - - int rval; int barp; char buffer[BUFSIZ]; char *t = NULL; - - fd_set readfds; - - struct timeval to; int readlen; - - int s = fileno(fp); for (readlen = max; max == 0 || readlen > 0; readlen -= blen) { - - FD_ZERO(&readfds); - - FD_SET(s, &readfds); - - to.tv_sec = 1; - - to.tv_usec = 0; - - - - if ((rval = select(s + 1, &readfds, (fd_set *)0, (fd_set *)0, &to)) > 0) - - { - - if (FD_ISSET(s, &readfds)) - - { if (linemode) { char *b; - --- 81,93 ---- *************** *** 132,143 **** else t = (char *)alloc_mem(tlen + 1); memcpy(t + btlen, buffer, blen); btlen = tlen; - - } - - } - - } - - else if (rval < 0) - - { - - break; } if (DisplayTransferStatus(tlen, max) == 1) - --- 119,124 ---- ------- Message 33 Received: from ra.ibr.cs.tu-bs.de by JIMI.CS.UNLV.EDU id aa24672; 20 Oct 94 7:34 PDT Received: from moocow.math.nat.tu-bs.de by ra.ibr.cs.tu-bs.de (5.65/1.341) id AA27193; Thu, 20 Oct 94 15:34:26 +0100 Received: by moocow (Linux Smail3.1.28.1 #4) id m0qxyb8-00017yC; Thu, 20 Oct 94 15:36 MET Message-Id: <m0qxyb8-00017yC@moocow> Date: Thu, 20 Oct 94 15:36 MET From: Mike Dowling <mike@moocow.math.nat.tu-bs.de> To: bug-chimera@cs.unlv.edu Subject: Graphics problem solved Reply-To: on.dowling@zib-berlin.de X-Attribution: M. Dowling Thanks to all those who wrote to me with advice as to how to turn on graphics with chimera. As I think that my difficulties will probably be fairly common, I shall briefly describe the difficulty and the solution. The problem: Chimera down loads the inline graphics, but only displays a cross where the graphics should be. The solution: Chimera needs and requires the netpbm binaries. It also needs and requires the giftoppm file, which is just a link to giftopnm. If your a linux user, then just down loading the binaries is not sufficient as you will also need the libgr.so.1.3 libs. If any of these is missing, or if you have an older libgr lib, then chimera will not complain, you will see no errors or warnings. You just won't get the graphics. Suggestion: Some of this information aught to be in a README file. Thanks again, Mike PS Now I can flush Mosaic, which is something I've often wanted to do. ------- Message 34 Received: from fxwidegw.fujixerox.co.jp by JIMI.CS.UNLV.EDU id aa26057; 20 Oct 94 19:02 PDT Received: from fxmxgw.fujixerox.co.jp (root@fxmxgw.fujixerox.co.jp [129.249.88.3]) by fxwidegw.fujixerox.co.jp (8.6.9+2.4Wb/3.3Wb-05/06/94-1.9) with ESMTP id KAA18023; Fri, 21 Oct 1994 10:59:40 +0900 Received: from fox.fax.iwa.fujixerox.co.jp (root@[129.249.196.167]) by fxmxgw.fujixerox.co.jp (8.6.9+2.4Wb/3.1W-02/17/94-fxmxgw/1.7) with ESMTP id KAA18553; Fri, 21 Oct 1994 10:59:32 +0900 Received: (from jun@localhost) by fox.fax.iwa.fujixerox.co.jp (8.6.9/3.3W-94082612) id KAA20205; Fri, 21 Oct 1994 10:59:26 +0900 Date: Fri, 21 Oct 1994 10:59:26 +0900 From: Junichi Kurokawa <jun@fox.fax.iwa.fujixerox.co.jp> Message-Id: <199410210159.KAA20205@fox.fax.iwa.fujixerox.co.jp> To: Jim.Rees@umich.edu CC: bug-chimera@cs.unlv.edu In-reply-to: <199410201208.VAA05800@fxmxgw.fujixerox.co.jp> (Jim.Rees@umich.edu) Subject: Re: [chimera-1.60] possible bugs, "source" and gifs Experts, Upon the previous bug report I filed, James Rees sent me a patch to fix the bugs. I compared two versions by switching between them back and forth with deleting the caches each time, and confirmed that both bugs got fixed. (1) "source" button on Chimera Home Page now gives the full html display. (2) gif images are now drawn correctly. Thanks for the patch! > Jim Regards, junichi - -- Junichi Kurokawa Image and Printing System Products Development Center Fuji Xerox Co., Ltd. ------- Message 35 Received: from fxwidegw.fujixerox.co.jp by JIMI.CS.UNLV.EDU id aa27073; 20 Oct 94 19:50 PDT Received: from fxmxgw.fujixerox.co.jp (root@fxmxgw.fujixerox.co.jp [129.249.88.3]) by fxwidegw.fujixerox.co.jp (8.6.9+2.4Wb/3.3Wb-05/06/94-1.9) with ESMTP id LAA18533 for <bug-chimera@cs.unlv.edu>; Fri, 21 Oct 1994 11:50:11 +0900 Received: from fox.fax.iwa.fujixerox.co.jp (root@[129.249.196.167]) by fxmxgw.fujixerox.co.jp (8.6.9+2.4Wb/3.1W-02/17/94-fxmxgw/1.7) with ESMTP id LAA20330 for <bug-chimera@cs.unlv.edu>; Fri, 21 Oct 1994 11:50:09 +0900 Received: (from jun@localhost) by fox.fax.iwa.fujixerox.co.jp (8.6.9/3.3W-94082612) id LAA20458; Fri, 21 Oct 1994 11:50:06 +0900 Date: Fri, 21 Oct 1994 11:50:06 +0900 From: Junichi Kurokawa <jun@fox.fax.iwa.fujixerox.co.jp> Message-Id: <199410210250.LAA20458@fox.fax.iwa.fujixerox.co.jp> To: bug-chimera@cs.unlv.edu Subject: [patch] proxy by resource, not by environ variables Experts, Recently I grabbed the latest version chimera-1.60, and accomodated a small change to the source so that it will find out the proxy server from resource database, rather than from environment variables. If you have barrierzone on your site and need proxy, try it. (1) assume the archive is unpacked and xmkmf -a is done. (2) in the chimera-1.60 directory, apply the patch. It touches the following three files only. * Common.tmpl * src/main.c * src/widget.h (3) rebuild chimera. (4) edit your ~/.Xdefaults or whatever suitable, add the following values. The `####' part is your appropriate port number. `*httpProxy: https://your.proxy.server:####/' `*gopherProxy: https://your.proxy.server:####/' `*ftpProxy: https://your.proxy.server:####/' `*waisProxy: https://your.proxy.server:####/' `*noProxy: https://internal.server(s)' (5) unset your `*_proxy' environment variables by hand. (6) run the patched chimera and try your favorite server. (7) when you set resource and environment variable differently, the environment variable takes precedence over the resource. Note: this patch =may not= be released outside the mailing list. I post it to encourage the list to see if the patch serves the intended purpose, rather than let it go as an unofficial modification. And hopefully John will take time to include this feature in the standard distribution. (I already sent a similar patch for older release.) Regards, junichi - -- Junichi Kurokawa Image and Printing System Products Development Center Fuji Xerox Co., Ltd. ------- Message 36 Received: from ra.ibr.cs.tu-bs.de by JIMI.CS.UNLV.EDU id aa15086; 21 Oct 94 5:16 PDT Received: from data by ra.ibr.cs.tu-bs.de (5.65/1.341) id AA10277; Fri, 21 Oct 94 13:16:19 +0100 Received: by data (4.1/SMI-4.1N) id AA04032; Fri, 21 Oct 94 13:15:59 +0100 Date: Fri, 21 Oct 94 13:15:59 +0100 From: Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de> Message-Id: <9410211215.AA04032@data> To: bug-chimera@cs.unlv.edu Subject: a core dump by a mistyped URL Reply-To: schoenw@ibr.cs.tu-bs.de Hi! I just typed chimera http:/www.cs.tu-bs.de/ with the missing // before the host name and chimera-1.60 dumped core (on a SUN Sparc running SunOS 4.1.1). The problem is that net_open(hostname, portno) gets called with hostname being a NULL pointer which is passed to inet_addr(). Perhaps a check for hostname==NULL and just using 127.0.0.1 or something like that would fix this small one (at least this would make sense for my broken html URL). Thanks for writing chimera. Good to have a small and handy WWW browser. Juergen ------- Message 37 Received: from mail.cs.tu-berlin.de by JIMI.CS.UNLV.EDU id aa06385; 22 Oct 94 6:57 PDT Received: from birka.cs.tu-berlin.de (czyborra@birka.cs.tu-berlin.de [141.23.58.11]) by mail.cs.tu-berlin.de (8.6.9/8.6.9) with ESMTP id OAA12912; Sat, 22 Oct 1994 14:55:32 +0100 Received: (czyborra@localhost) by birka.cs.tu-berlin.de (8.6.9/8.6.6) id OAA21867; Sat, 22 Oct 1994 14:55:29 +0100 From: Roman Czyborra <czyborra@cs.tu-berlin.de> MIME-Version: 1.0 To: Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de> Cc: bug-chimera@cs.unlv.edu Subject: Re: a core dump by a mistyped URL In-Reply-To: <9410211215.AA04032@data> by schoenw@ibr.cs.tu-bs.de dated 1994-10-21 13:15:59 Date: Sat, 22 Oct 1994 14:55:27 +0100 Message-ID: <czyborra941022145521862@birka.cs.tu-berlin.de> > I just typed chimera http:/www.cs.tu-bs.de/ with the missing // > before the host name and chimera-1.60 dumped core. Perhaps a check > for hostname==NULL and just using 127.0.0.1 or something like that > would fix this small one. Shouldn't that fall back on "www" instead of "localhost"? "www" seems to be the emerging standard alias for the machine serving HTTP requests, just like Mosaic calls "news" for NNTP. ------- Message 38 Received: from ra.ibr.cs.tu-bs.de by JIMI.CS.UNLV.EDU id aa12061; 22 Oct 94 10:46 PDT Received: from data by ra.ibr.cs.tu-bs.de (5.65/1.341) id AA25093; Sat, 22 Oct 94 18:46:22 +0100 Received: by data (4.1/SMI-4.1N) id AA15160; Sat, 22 Oct 94 18:45:41 +0100 Date: Sat, 22 Oct 94 18:45:41 +0100 From: Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de> Message-Id: <9410221745.AA15160@data> To: czyborra@cs.tu-berlin.de Cc: bug-chimera@cs.unlv.edu In-Reply-To: <czyborra941022145521862@birka.cs.tu-berlin.de> (message from Roman Czyborra on Sat, 22 Oct 1994 14:55:27 +0100) Subject: Re: a core dump by a mistyped URL Reply-To: schoenw@ibr.cs.tu-bs.de Hi! > I just typed chimera http:/www.cs.tu-bs.de/ with the missing // > before the host name and chimera-1.60 dumped core. Perhaps a check > for hostname==NULL and just using 127.0.0.1 or something like that > would fix this small one. Roman> Shouldn't that fall back on "www" instead of "localhost"? "www" seems Roman> to be the emerging standard alias for the machine serving HTTP Roman> requests, just like Mosaic calls "news" for NNTP. Agreed, "www" may be a good choice. Juergen ------- Message 39 Received: from citi.umich.edu by JIMI.CS.UNLV.EDU id aa16788; 22 Oct 94 14:18 PDT Received: from citi.umich.edu by citi.umich.edu for czyborra@cs.tu-berlin.de bug-chimera@cs.unlv.edu with SMTP; Sat, 22 Oct 94 17:17:33 -0400 From: Jim.Rees@umich.edu To: Roman Czyborra <czyborra@cs.tu-berlin.de> Cc: bug-chimera@cs.unlv.edu Date: Sat, 22 Oct 94 17:17:25 EDT Subject: Re: a core dump by a mistyped URL Sender: rees@citi.umich.edu In-Reply-To: Roman Czyborra, Sat, 22 Oct 94 14:55:27 BST Shouldn't that fall back on "www" instead of "localhost"? "www" seems to be the emerging standard alias for the machine serving HTTP requests, just like Mosaic calls "news" for NNTP. No, absolutely not. That would be the wrong thing to do. A missing host part should either be illegal or should be assumed "localhost." I vote for illegal, myself, although it might be instructive to see whether there is a url spec somewhere that would say. ------- Message 40 Received: from cephas.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa20506; 22 Oct 94 16:38 PDT To: Jim.Rees@umich.edu, Roman Czyborra <czyborra@cs.tu-berlin.de> cc: bug-chimera@cs.unlv.edu Subject: Re: a core dump by a mistyped URL In-reply-to: Your message of "Sat, 22 Oct 1994 17:17:25 EDT." Date: Sat, 22 Oct 1994 16:38:16 -0700 From: John Kilburg <john@cephas.ISRI.UNLV.EDU> > Shouldn't that fall back on "www" instead of "localhost"? "www" seems > to be the emerging standard alias for the machine serving HTTP > requests, just like Mosaic calls "news" for NNTP. > >No, absolutely not. That would be the wrong thing to do. A missing host >part should either be illegal or should be assumed "localhost." I vote for >illegal, myself, although it might be instructive to see whether there is a >url spec somewhere that would say. I am probably going to require full URLs on the command line except with local 'file' URLs. The reason is that each protocol requires different defaults and chimera wants to treat all URLs the same. This will have to change eventually because the guy who devised the URL scheme decided to make different protocols treat URLs differently. For example, relative URLs for HTTP and NNTP are different so there has to be code to handle each one. I'm not sure why. Maybe they like to write lots of code. -john ------- Message 41 Received: from cephas.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa25547; 24 Oct 94 5:14 PDT To: bug-chimera@cephas.ISRI.UNLV.EDU Subject: 1.61 status Date: Mon, 24 Oct 1994 05:14:10 -0700 From: John Kilburg <john@cephas.ISRI.UNLV.EDU> If you haven't moved up to 1.60 from a beta version yet then wait a bit longer. 1.61 should be coming out in the next couple of days. 1.61 is mostly a maintenance release to remove the nastier bugs from 1.60: - - dumps core on some types of relative URLs - - dumps core when given a command line URL - - problems in EscapeURL() - - dumps core in WriteCache() - - stdio functions has been removed from ReadInput() so select() can be used - - authentication problems This list isn't complete. If 1.61 turns out to be reasonbly stable then there will probably be another long break as I mess around with some extensive changes. As usual, thanks for all of the bug reports, suggestions, and fixes. -john ------- Message 42 Received: from cephas.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa19511; 24 Oct 94 17:23 PDT To: Junichi Kurokawa <jun@fox.fax.iwa.fujixerox.co.jp> cc: bug-chimera@cs.unlv.edu Subject: Re: [patch] proxy by resource, not by environ variables In-reply-to: Your message of "Fri, 21 Oct 1994 11:50:06 +0900." <199410210250.LAA20458@fox.fax.iwa.fujixerox.co.jp> Date: Mon, 24 Oct 1994 17:23:53 -0700 From: John Kilburg <john@cephas.ISRI.UNLV.EDU> I'm not sure setenv() is portable. What machine/OS are you using? -john >Experts, > >Recently I grabbed the latest version chimera-1.60, and accomodated a >small change to the source so that it will find out the proxy server >from resource database, rather than from environment variables. > >If you have barrierzone on your site and need proxy, try it. > >(1) assume the archive is unpacked and xmkmf -a is done. > >(2) in the chimera-1.60 directory, apply the patch. It touches the > following three files only. > > * Common.tmpl > * src/main.c > * src/widget.h > >(3) rebuild chimera. > >(4) edit your ~/.Xdefaults or whatever suitable, add the following > values. The `####' part is your appropriate port number. > > `*httpProxy: https://your.proxy.server:####/' > `*gopherProxy: https://your.proxy.server:####/' > `*ftpProxy: https://your.proxy.server:####/' > `*waisProxy: https://your.proxy.server:####/' > `*noProxy: https://internal.server(s)' > >(5) unset your `*_proxy' environment variables by hand. > >(6) run the patched chimera and try your favorite server. > >(7) when you set resource and environment variable differently, the > environment variable takes precedence over the resource. > >Note: this patch =may not= be released outside the mailing list. I >post it to encourage the list to see if the patch serves the intended >purpose, rather than let it go as an unofficial modification. And >hopefully John will take time to include this feature in the standard >distribution. (I already sent a similar patch for older release.) > >Regards, >junichi > >-- >Junichi Kurokawa >Image and Printing System Products Development Center >Fuji Xerox Co., Ltd. ------- Message 43 Received: from fxwidegw.fujixerox.co.jp by JIMI.CS.UNLV.EDU id aa24174; 24 Oct 94 20:08 PDT Received: from fxmxgw.fujixerox.co.jp (root@fxmxgw.fujixerox.co.jp [129.249.88.3]) by fxwidegw.fujixerox.co.jp (8.6.9+2.4Wb/3.3Wb-05/06/94-1.9) with ESMTP id MAA23148; Tue, 25 Oct 1994 12:07:50 +0900 Received: from fox.fax.iwa.fujixerox.co.jp (root@[129.249.196.167]) by fxmxgw.fujixerox.co.jp (8.6.9+2.4Wb/3.1W-02/17/94-fxmxgw/1.7) with ESMTP id MAA12148; Tue, 25 Oct 1994 12:07:49 +0900 Received: (from jun@localhost) by fox.fax.iwa.fujixerox.co.jp (8.6.9/3.3W-94082612) id MAA06079; Tue, 25 Oct 1994 12:07:47 +0900 Date: Tue, 25 Oct 1994 12:07:47 +0900 From: Junichi Kurokawa <jun@fox.fax.iwa.fujixerox.co.jp> Message-Id: <199410250307.MAA06079@fox.fax.iwa.fujixerox.co.jp> To: john@cephas.ISRI.UNLV.EDU CC: bug-chimera@cs.unlv.edu In-reply-to: <199410250031.JAA06930@fxmxgw.fujixerox.co.jp> (message from John Kilburg on Mon, 24 Oct 1994 17:23:53 -0700) Subject: Re: [patch] proxy by resource, not by environ variables >>>>> "J" == John Kilburg <john@cephas.ISRI.UNLV.EDU> writes: J> I'm not sure setenv() is portable. What machine/OS are you J> using? -john I guess setenv(3) is portable across most Un#x flavours. I use FreeBSD-1.1.5.1 on an IBM compatible. A good BSD derivative, I really like it. One thing you should be aware of, and probably why you should eventually move to using X resources is that those `*_proxy' environment variables could conflict with the ones the httpd daemon uses, when one runs both. Apparently all such variables, head on :-) One another symptom to go: with cacheOff: True, the already visited anchors no longer change the color. When cacheOff: removed, then they do. Version: 1.60. Fix: currently no idea. Cheers, junichi - -- Junichi Kurokawa Image and Printing System Products Development Center Fuji Xerox Co., Ltd. ------- Message 44 Received: from igw.merck.com by JIMI.CS.UNLV.EDU id aa26779; 24 Oct 94 21:08 PDT Received: by igw.merck.com (5.65/fma-120691); id AA08612; Tue, 25 Oct 94 00:14:28 -0400 Message-Id: <9410250414.AA08612@igw.merck.com> From: Anthony Starks <anthony_starks@merck.com> Subject: a different urlgrab To: bug-chimera@cs.unlv.edu Date: Tue, 25 Oct 1994 00:05:16 -0400 (EDT) Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3294 here is my version of urlgrab. It writes the url to stdout instead of the cache. - ----------------------------------- /* * urlgrab.c --- Fetches a URL * * * Copyright (C) 1994, John Kilburg. * * You may distribute this code freely as long as it is used only for academic, * research, and internal business uses only, without a fee. You may distribute the * binary and source code to third parties provided that the copyright notice and * this statement appears on all copies and that no charge is associated with such * copies. * * If you make and distribute modified versions of the source or binaries then you must * inform me (John Kilburg) of the distribution. You must also give me credit for * the original in the source and documentation but you must indicate that * modifications were made. * * If you wish to make commercial use of the source or binaries you should contact * me, to negotiate an appropriate license for such commercial use. Commercial use * includes (1) integration of all or part of the source code into a product for * sale or license by or on behalf of Licensee to third parties, or (2) * distribution of the binary code or source code to third parties that need it to * utilize a commercial product sold or licensed by you or on your behalf. * * This software is provided "as is" without expressed or implied warranty. It is not * intended to be used for any particular purpose. I shall not be liable for any * damages suffered by users of this software. USE AT YOUR OWN RISK. * ------------------------------------------------------------- * * * Modified by Anthony Starks (anthony_starks@merck.com) to write the document standard * output. * */ #include <stdio.h> #include "url.h" #include "mime.h" #include "document.h" #include "options.h" void DisplayTransferStatus() { return; } void main(argc, argv) int argc; char *argv[]; { URLParts *up; Document *d; Protocol *plist; MIMEType *mtlist; int i, size; mtlist = ReadMIMETypeFiles(MIME_TYPE_FILES); plist = ReadProtocolFiles(PROTOCOL_FILES); if (argc > 1) { for (i = 1; i < argc; i++) { up = ParseURL(argv[i]); if (up == NULL) exit(1); d = LoadDocument(up, plist, mtlist); size = Putdoc(d, stdout); DestroyDocument(d); DestroyURLParts(up); } exit(0); } else { fprintf(stderr, "%s url...\n", argv[0]); exit(1); } } /* * Putdoc -- write a document */ Putdoc(d, fp) Document *d; FILE *fp; { char *u; fprintf(fp, "HTTP/1.0 200 OK\n"); u = MakeURL(d->up); fprintf(fp, "X-URL: %s\n", u); free(u); if (d->content) fprintf(fp, "Content-type: %s\n", d->content); else fprintf(fp, "Content-type: x-unknown/x-unknown\n"); fprintf(fp, "Content-length: %d\n", d->len); if (d->ptext) { fprintf(fp, "X-PContent-length: %d\n", d->plen); if (d->pcontent) fprintf(fp, "X-PContent-type: %s\n", d->pcontent); else fprintf(fp, "X-PContent-type: x-unknown/x-unknown\n"); } fprintf(fp, "\n"); fwrite(d->text, 1, d->len, fp); if (d->ptext != NULL) fwrite(d->ptext, 1, d->plen, fp); return d->len; } - -- Anthony Starks Merck Research Laboratories Anthony_Starks@Merck.Com ------- Message 45 Received: from igw.merck.com by JIMI.CS.UNLV.EDU id aa27012; 24 Oct 94 21:17 PDT Received: by igw.merck.com (5.65/fma-120691); id AA09179; Tue, 25 Oct 94 00:23:29 -0400 Message-Id: <9410250423.AA09179@igw.merck.com> From: Anthony Starks <anthony_starks@merck.com> Subject: makefile changes for new urlgrab To: bug-chimera@cs.unlv.edu Date: Tue, 25 Oct 1994 00:14:12 -0400 (EDT) Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 497 my urlgrab only needs these .o files: url.o net.o ftp.o gopher.o http.o \ util.o document.o local.o mime.o input.o \ auth.o Adjust your Makefile: UOBJS = url.o net.o ftp.o gopher.o http.o \ util.o document.o local.o mime.o input.o \ auth.o urlgrab: urlgrab.o $(UOBJS) $(RM) $@ $(CC) -o $@ urlgrab.o $(UOBJS) $(LDOPTIONS) $(SOCKSLIB) $(TERMLIB)\ $(EFFLAGS) $(EFENCE) $(LDLIBS) $(EXTRA_LOAD_FLAGS) - -- Anthony Starks Merck Research Laboratories Anthony_Starks@Merck.Com ------- Message 46 Received: from concorde.inria.fr by JIMI.CS.UNLV.EDU id aa15631; 25 Oct 94 7:31 PDT Received: from fantomas.inria.fr (fantomas.inria.fr [128.93.11.34]) by concorde.inria.fr (8.6.9/8.6.9) with ESMTP id PAA27318 for <bug-chimera@cs.unlv.edu>; Tue, 25 Oct 1994 15:30:55 +0100 Received: (from lasgout@localhost) by fantomas.inria.fr (8.6.8/8.6.6) id PAA13854; Tue, 25 Oct 1994 15:30:55 +0100 Date: Tue, 25 Oct 1994 15:30:55 +0100 From: Jean-Marc Lasgouttes <Jean-Marc.Lasgouttes@inria.fr> Message-Id: <199410251430.PAA13854@fantomas.inria.fr> To: bug-chimera@cs.unlv.edu Subject: Chimera and speed Reply-to: Jean-Marc.Lasgouttes@inria.fr Hi everybody, I have recently tried Netscape and have been very impressed in one respect : speed. Now, I prefer to use Chimera but this speed factor is bugging me. I do not really know how the speed increase is achieved, but I can think of several factors : - - Parts of documents are displayed as soon as they are received. - - The scrollbars and such are active during this time. This mean that you can activate a link of a document before the download is complete. - - The image downloading is also very nice: netscape reserves the size of the images before downloading them and has a nice way to present them gradually (I guess this is currently impossible with netpbm). My problem is that I do not really want to use Netscape. I want to stick with Chimera, because I like it. But the speed difference makes you feel that it does not use the same network connection :-). Would it be very difficult to display text as soon as it is received, while having a functionnal interface? Or is it too much work with the current architecture of Chimera? Jean-Marc. ------- Message 47 Received: from cephas.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa22418; 26 Oct 94 14:27 PDT To: bug-chimera@cephas.ISRI.UNLV.EDU Subject: 1.61 Date: Wed, 26 Oct 1994 14:27:48 -0700 From: John Kilburg <john@cephas.ISRI.UNLV.EDU> I put it out for ftp but it turns out that it has problems that need to be fixed. Please don't grab it! -john ------- Message 48 Received: from cephas.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa25727; 26 Oct 94 15:22 PDT To: Jean-Marc.Lasgouttes@inria.fr cc: bug-chimera@cs.unlv.edu Subject: Re: Chimera and speed In-reply-to: Your message of "Tue, 25 Oct 1994 15:30:55 BST." <199410251430.PAA13854@fantomas.inria.fr> Date: Wed, 26 Oct 1994 15:22:38 -0700 From: John Kilburg <john@cephas.ISRI.UNLV.EDU> >I have recently tried Netscape and have been very impressed in one >respect : speed. Now, I prefer to use Chimera but this speed factor >is bugging me. > >I do not really know how the speed increase is achieved, but I can >think of several factors : >- Parts of documents are displayed as soon as they are received. >- The scrollbars and such are active during this time. This mean that >you can activate a link of a document before the download is complete. >- The image downloading is also very nice: netscape reserves the size of >the images before downloading them and has a nice way to present them >gradually (I guess this is currently impossible with netpbm). > >My problem is that I do not really want to use Netscape. I want to >stick with Chimera, because I like it. But the speed difference makes >you feel that it does not use the same network connection :-). > >Would it be very difficult to display text as soon as it is received, >while having a functionnal interface? Or is it too much work with the >current architecture of Chimera? I plan on doing some things to increase performance: - - GIFs handled by chimera instead of netpbm (saves disk space, too) - - Multiple downloads at once I think once I rearrange the code to deal with multiple downloads then the async text display will follow. -john ------- Message 49 Received: from cephas.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa19203; 27 Oct 94 1:26 PDT To: bug-chimera@cephas.ISRI.UNLV.EDU Subject: 1.61 Date: Thu, 27 Oct 1994 01:26:16 -0700 From: John Kilburg <john@cephas.ISRI.UNLV.EDU> I just put it out for anon ftp: ftp://ftp.cs.unlv.edu/pub/chimera/chimera-1.61.tar.gz I'll let the list bash on it for a day or two and then announce it to the world. -john ------- Message 50 Received: from bibsyst.bibsyst.no by JIMI.CS.UNLV.EDU id aa21901; 27 Oct 94 3:42 PDT Received: by bibsyst.bibsyst.no (Smail3.1.28.1 #12) id m0r0SHu-0004UwC; Thu, 27 Oct 94 11:42 WET Message-Id: <m0r0SHu-0004UwC@bibsyst.bibsyst.no> Date: Thu, 27 Oct 94 11:42 WET From: Tore Morkemo <tore@bibsyst.no> To: bug-chimera@cs.unlv.edu Subject: more text-resources Hi! We have translated all the chimera text's into norwegian and it look really nice. There's only a few texts which can't be changed. From main.c: SetTitle("Displaying document..."); SetTitle("Downloading document..."); if (max > 0) sprintf (buffer, "%d bytes out of %d loaded", n, max); else sprintf (buffer, "%d bytes loaded", n); SetTitle(buffer); Would it be possible to make these into resources to so we can get a complete norwegian WWW-browser? - -- Tore Morkemo. *-----------------------------------------------------------------------------* Tore Morkemo, Bibliotek-Systemer A/S, Box 2093 Stubber|d, 3271 Larvik, Norway Tel: +47 33 11 68 00 Fax: +47 33 11 68 22 email: tore@bibsyst.no *-----------------------------------------------------------------------------* ------- Message 51 Received: from cephas.ISRI.UNLV.EDU by JIMI.CS.UNLV.EDU id aa22214; 27 Oct 94 4:00 PDT To: Tore Morkemo <tore@bibsyst.no> cc: bug-chimera@cs.unlv.edu Subject: Re: more text-resources In-reply-to: Your message of "Thu, 27 Oct 1994 11:42:00 +0700." <m0r0SHu-0004UwC@bibsyst.bibsyst.no> Date: Thu, 27 Oct 1994 04:00:00 -0700 From: John Kilburg <john@cephas.ISRI.UNLV.EDU> >We have translated all the chimera text's into norwegian and it look really >nice. There's only a few texts which can't be changed. > >From main.c: > > >SetTitle("Displaying document..."); > >SetTitle("Downloading document..."); > >if (max > 0) sprintf (buffer, "%d bytes out of %d loaded", n, max); >else sprintf (buffer, "%d bytes loaded", n); > >SetTitle(buffer); > >Would it be possible to make these into resources to so we can get a complete >norwegian WWW-browser? Yes. I am planning on providing a way to change the messages at run-time real soon now. -john ------- Message 52 Received: from citi.umich.edu by JIMI.CS.UNLV.EDU id aa19671; 27 Oct 94 17:43 PDT Received: from citi.umich.edu by citi.umich.edu for john@cephas.ISRI.UNLV.EDU bug-chimera@cephas.ISRI.UNLV.EDU with SMTP; Thu, 27 Oct 94 20:42:04 -0400 From: Jim.Rees@umich.edu To: John Kilburg <john@cephas.ISRI.UNLV.EDU> Cc: bug-chimera@cephas.ISRI.UNLV.EDU Date: Thu, 27 Oct 94 20:41:57 EDT Subject: Re: 1.61 Sender: rees@citi.umich.edu In-Reply-To: John Kilburg, Thu, 27 Oct 94 01:26:16 PDT After making the same set of changes I have to make at every single release (rm Makefiles, options.h, add #include <sys/types.h> to util.c) it builds and seems to be quite solid. ------- Message 53 Received: from relay3.UU.NET by JIMI.CS.UNLV.EDU id aa05694; 28 Oct 94 6:26 PDT Received: from uucp7.UU.NET by relay3.UU.NET with SMTP id QQxnon22143; Fri, 28 Oct 1994 09:26:36 -0400 Date: Fri, 28 Oct 1994 09:26:36 -0400 From: nicnet!GISD!pkv@uunet.uu.net Message-Id: <QQxnon22143.199410281326@relay3.UU.NET> Received: from nicnet.UUCP by uucp7.UU.NET with UUCP/RMAIL ; Fri, 28 Oct 1994 09:26:38 -0400 To: nicnet!uunet!cs.unlv.edu!bug-chimera@uunet.uu.net Cc: nicnet!uunet!cs.unlv.edu!john@uunet.uu.net Subject: installing Chimera ... Received: from GISD by nicnet.nic.in; Fri, 28 Oct 1994 18:37 IST Content-Type: text Content-Length: 437 Hi, I have just now loaded CHimera-1.61, and trying to install it. I am going thru the INSTALL, and have modified the options and Common.tmpl files. However, at the next step, i have got stumped, as there is no xmkmf available to us on this system. Do answer me what should i do? really desperate ... BTW, I am on a 486 with SVR4.0 and X11R4 with OPEN LOOK. Do respond me by Email, as i am not on this list. Prabhat pkv@GISD.nic.in ------- End of Forwarded Messages