From icon-group-sender Tue Sep 8 16:27:28 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id QAA26033 for ; Tue, 8 Sep 1998 16:27:28 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA28866; Tue, 8 Sep 1998 16:27:01 -0700 To: icon-group@optima.CS.Arizona.EDU Date: Tue, 08 Sep 1998 23:46:34 GMT From: David Feustel Message-Id: <35F551C0.E6DA1515@ix.netcom.com> Organization: Slurp News Feeds Sender: icon-group-request@optima.CS.Arizona.EDU Subject: Ansi C version of Icon Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Are there any other Icon features besides coroutines that would preclude an Ansi C version of the commandline version of Icon? -- David Feustel 219-483-1857 From icon-group-sender Wed Sep 9 12:40:45 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id MAA10499 for ; Wed, 9 Sep 1998 12:40:45 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA29800; Wed, 9 Sep 1998 12:40:18 -0700 To: icon-group@optima.CS.Arizona.EDU Date: 9 Sep 1998 15:13:03 GMT From: espie@liafa.jussieu.fr (Marc Espie) Message-Id: <6t65tv$68d$1@vishnu.jussieu.fr> Organization: None Sender: icon-group-request@optima.CS.Arizona.EDU References: <35F551C0.E6DA1515@ix.netcom.com> Subject: Re: Ansi C version of Icon Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO In article <35F551C0.E6DA1515@ix.netcom.com>, David Feustel wrote: >Are there any other Icon features besides coroutines that would >preclude an Ansi C version of the commandline version of Icon? > If you want STRICT ansi C, you're asking for trouble, as malloc() is limited to 64K thanks to brain-dead architectures. Apart from that, this should be feasible... the way Icon configures and builds is not a pretty sight, it would need some rather extensive efforts to clean that up and get it to work with STRICT ansi. -- Marc Espie |anime, sf, juggling, unicycle, acrobatics, comics... |AmigaOS, OpenBSD, C++, perl, Icon, PostScript... | `real programmers don't die, they just get out of beta' From icon-group-sender Wed Sep 9 12:41:01 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id MAA10502 for ; Wed, 9 Sep 1998 12:41:00 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA29749; Wed, 9 Sep 1998 12:40:34 -0700 To: icon-group@optima.CS.Arizona.EDU Date: 09 Sep 1998 12:47:41 -0400 From: davidf@mks.com (David J. Fiander) Message-Id: Organization: Mortice Kern Systems Inc. Sender: icon-group-request@optima.CS.Arizona.EDU References: <35F551C0.E6DA1515@ix.netcom.com>, <6t65tv$68d$1@vishnu.jussieu.fr> Subject: Re: Ansi C version of Icon Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO espie@liafa.jussieu.fr (Marc Espie) writes: > If you want STRICT ansi C, you're asking for trouble, as malloc() is > limited to 64K thanks to brain-dead architectures. I thought this was such a strange comment that I had to go check my copy of the ANSI standard. As I suspected, the C standard places no limits on the amount of memory that one can request via malloc(). Well, the size has to fit into a size_t, so your limited to objects whose size can be described by one of those. - David From icon-group-sender Wed Sep 9 16:57:34 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id QAA04218 for ; Wed, 9 Sep 1998 16:57:34 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA30260; Wed, 9 Sep 1998 16:57:07 -0700 To: icon-group@optima.CS.Arizona.EDU Date: 9 Sep 1998 13:14:06 -0700 From: gmt@optima.CS.Arizona.EDU (Gregg Townsend) Message-Id: <6t6nie$a18@hawk.CS.Arizona.EDU> Organization: University of Arizona CS Department, Tucson AZ Sender: icon-group-request@optima.CS.Arizona.EDU References: <35F551C0.E6DA1515@ix.netcom.com> Subject: Re: Ansi C version of Icon Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO David Feustel wrote: > Are there any other Icon features besides coroutines that would > preclude an Ansi C version of the commandline version of Icon? Actually, it would be possible to write a nearly full version of Icon using ANSI C, including co-expressions. Only a few things around the fringes (such as dynamic loading, pipes, and &host) can't be done in strict ANSI C. The current C implementation, though, has several other non-ANSI aspects. The system-dependent context switch code for co-expressions is one, but the memory allocation and garbage collection code is more significant. Several assumptions about pointer behavior exceed the promises of ANSI C, and these pervade the whole run-time system. --------------------------------------------------------------------------- Gregg Townsend Gould-Simpson Building gmt@cs.arizona.edu Staff Scientist 1040 E. 4th St. 32 13 45N 110 57 16W Dept. of Computer Science PO Box 210077 tel: +1 520 621 4325 The University of Arizona Tucson, AZ 85721-0077 fax: +1 520 621 4246 From icon-group-sender Wed Sep 9 16:57:41 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id QAA04236 for ; Wed, 9 Sep 1998 16:57:40 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA30205; Wed, 9 Sep 1998 16:57:14 -0700 Date: Thu, 10 Sep 1998 12:00:33 +1200 (NZST) From: "Richard A. O'Keefe" Message-Id: <199809100000.MAA30388@atlas.otago.ac.nz> To: davidf@mks.com, icon-group@optima.CS.Arizona.EDU Subject: Re: Ansi C version of Icon Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO espie@liafa.jussieu.fr (Marc Espie) writes: > If you want STRICT ansi C, you're asking for trouble, as malloc() is > limited to 64K thanks to brain-dead architectures. As I suspected, the C standard places no limits on the amount of memory that one can request via malloc(). Well, the size has to fit into a size_t You weren't looking in the right place. The C standard only guarantees that at least one program can have at least one object that is up to 32767 bytes in size. Conforming C implementations are NOT required to support objects any bigger than 32767 bytes *however* allocated. Conforming C implementations are also allowed to support objects bigger than 4GB if they want to, but conforming *programs* can't rely on that. From icon-group-sender Thu Sep 10 07:46:00 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id HAA15772 for ; Thu, 10 Sep 1998 07:45:59 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA30480; Thu, 10 Sep 1998 07:45:32 -0700 Message-Id: <35F73155.1816@gte.net> Date: Wed, 09 Sep 1998 20:54:29 -0500 From: MJE Reply-To: evans@gte.net Organization: None X-Mailer: Mozilla 3.01 (Win95; I) Mime-Version: 1.0 To: icon-group@optima.CS.Arizona.EDU Subject: Context Switching References: <35F551C0.E6DA1515@ix.netcom.com> <6t6nie$a18@hawk.CS.Arizona.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Errors-To: icon-group-errors@optima.CS.Arizona.EDU Content-Transfer-Encoding: 7bit Status: RO This is one aspect of Icon I don't like. Why does there have to be custom push/pop assembly for context switching? Can't another (safer, more portable) form of context-switching be used? Seems to me there should be a better way, but maybe I don't really understand how the context switching works in Icon. Best regards, Mark Gregg Townsend wrote: > > David Feustel wrote: > > Are there any other Icon features besides coroutines that would > > preclude an Ansi C version of the commandline version of Icon? > > Actually, it would be possible to write a nearly full version of Icon > using ANSI C, including co-expressions. Only a few things around the > fringes (such as dynamic loading, pipes, and &host) can't be done in > strict ANSI C. > > The current C implementation, though, has several other non-ANSI aspects. > The system-dependent context switch code for co-expressions is one, but > the memory allocation and garbage collection code is more significant. > Several assumptions about pointer behavior exceed the promises of ANSI C, > and these pervade the whole run-time system. > > --------------------------------------------------------------------------- > Gregg Townsend Gould-Simpson Building gmt@cs.arizona.edu > Staff Scientist 1040 E. 4th St. 32 13 45N 110 57 16W > Dept. of Computer Science PO Box 210077 tel: +1 520 621 4325 > The University of Arizona Tucson, AZ 85721-0077 fax: +1 520 621 4246 From icon-group-sender Thu Sep 10 07:45:45 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id HAA15769 for ; Thu, 10 Sep 1998 07:45:44 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA29716; Thu, 10 Sep 1998 07:45:17 -0700 To: icon-group@optima.CS.Arizona.EDU Date: Thu, 10 Sep 1998 09:56:48 +0900 From: Eric Hildum Message-Id: <35F723CF.76B3CC97@Japan.NCR.COM> Organization: NCR Japan Sender: icon-group-request@optima.CS.Arizona.EDU Subject: Unicode support or support for non-Ascii based character manipulation? Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Icon has been a very interesting language for string manipulation, however, the limit of supporting only ASCII makes it less useful for non-English language work. With the computer industry heading towards Unicode support, it should be possible to begin including support for non-English and non alphabetic languages. However, I suspect this would like lead to the need to change or generalize the semantics of a number of the string manipulation and character intrinsics. Has anyone thought about this yet? What does string and pattern matching mean in, for example, Japanese? -- --------------------------- Eric Hildum Eric.Hildum@Japan.NCR.COM From icon-group-sender Thu Sep 10 12:24:31 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id MAA26222 for ; Thu, 10 Sep 1998 12:24:31 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA31099; Thu, 10 Sep 1998 12:24:04 -0700 From: gep2@computek.net Date: Thu, 10 Sep 1998 13:46:57 -0500 (CDT) Message-Id: <199809101846.NAA18441@mail.cmpu.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: Unicode support or support for non-Ascii based character manipulation? To: icon-group@optima.CS.Arizona.EDU X-Mailer: SPRY Mail Version: 04.00.06.17 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Errors-To: icon-group-errors@optima.CS.Arizona.EDU Content-Transfer-Encoding: 7bit Status: RO > Icon has been a very interesting language for string manipulation, Certainly! If not the MOST interesting language for such purposes. > however, the limit of supporting only ASCII Actually, that's not really true. Icon is much more free of "supporting ONLY ASCII" than C, for example. (I don't know how true this is about things like conversions... does Icon automatically support EBCDIC character assignments, for example, if generated on an EBCDIC system?) Certainly though there are issues that come up with supporting international characters, and in part that's due to the fact that there doesn't seem to be any real international agreement on how (at least some) other natural languages map their alphabetic characters into (at least) an 8-bit byte. Hebrew is one example, where there seem to be at least three different competing "standards" for where the characters are mapped. > makes it less useful for non-English language work. Well, I agree that it's perhaps less useful than it MIGHT be, but I still suspect it's (far!) more useful than OTHER programming languages are for these kinds of things. > With the computer industry heading towards Unicode support, Okay, I don't dispute that this move is happening but personally I still don't very much like it. The fact is that (at least here in the Western Hemisphere, where probably most of the world's computers are used) an eight-bit byte is already quite sufficient for most purposes, and doubling it comes at a cost in complexity and storage (RAM, disk, tape, whatever) which is simply very, very hard to justify on any genuine economic basis. If other countries have more difficult (or huge) character sets, that is (while a fact of life) simply an inherent disadvantage of their culture (and note that I'm not intending that as a slam or value judgement, it just IS the way it is), and I don't see a terribly convincing argument why the other countries (without that disadvantage) ought to pay the price too, just in order to artificially level the playing field. > ...it should be possible to begin including support for non-English and non alphabetic languages. I think that a lot of the basic manipulations and features in Icon (tables, sets, etc) are probably insensitive to the character mapping used. And Icon does seem to be pretty much (totally?) eight-bit clean (unlike C), which at least gives one the ability to construct stuff on top of it to support other languages. One issue, of course, is the one I mentioned earlier... conversions, although numeric formatting is one other specific example of a potential problem area. Certainly not all cultures prefer Arabic numerals. Another issue, perhaps unique to Icon, is the implementation of "character set" datatypes, which I'd suspect would end up being quite different for a language containing 65,536 distinct characters... since the character set data representation, presumably unless a different implementation technique were used, would be not twice but 256 times larger than for an eight-bit character set. I can certainly understand and appreciate the problems that the huge character sets used in some eastern countries have played for them, and frankly have been surprised by the extent to which solutions for things like keyboards have been mastered. And text processing with such large character sets certainly must represent a whole series of unique challenges, so I can understand the interest in those countries in something like Icon for attacking them. > Has anyone thought about this yet? What does string and pattern matching mean in, for example, Japanese? I have given the matter some thought, although just as an 'outside observer'. I would presume that a "full/nice" implementation for such languages would result in simply processing Unicode-like 16-bit characters, with everything that involves. At *some* point, barring having complete 16-bit-byte uniformity across everything from CPUs and operating systems to peripheral devices, there might have to be some conversions and "glue" interface work done, and classically it's at those border/edge regions that the seams tend to be less than pretty. Certainly one of the more interesting Icon-related issues I've seen come up here in a while. I seem to recall it was mentioned briefly some time ago (perhaps that was on the SNOBOL4 list instead?) but didn't go very far at the time. Gordon Peterson http://www.computek.net/public/gep2/ Support the Anti-SPAM Amendment! Join at http://www.cauce.org/ From icon-group-sender Thu Sep 10 16:54:52 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id QAA04917 for ; Thu, 10 Sep 1998 16:54:52 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA31445; Thu, 10 Sep 1998 16:54:25 -0700 To: icon-group@optima.CS.Arizona.EDU Date: 10 Sep 1998 20:00:24 GMT From: jeffery@cs.utsa.edu (Clinton Jeffery) Message-Id: <6t9b4o$8rs$1@ringer.cs.utsa.edu> Organization: The University of Texas at San Antonio Sender: icon-group-request@optima.CS.Arizona.EDU References: <35F723CF.76B3CC97@Japan.NCR.COM> Reply-To: jeffery@cs.utsa.edu Subject: Re: Unicode support or support for non-Ascii based character manipulation? Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Eric Hildum (Eric.Hildum@Japan.NCR.COM) wrote (and I paraphrase/edited): : Icon ... supporting only ASCII makes it less useful for non-English language : With Unicode... it should be possible to begin including support for : non-English and non alphabetic languages. : Has anyone thought about this yet? What does string and pattern matching : mean in, for example, Japanese? 1. Other folks have been thinking about it, especially Icon users in Asia. For example, a Chinese version of Icon has been done by researchers in China. 2. Going to Unicode might not be *that* difficult, but I think Unicode isn't really as widely adopted as you might suggest. Many people seem to be using mixed 8/16-bit strings. 3. The semantics of string and pattern matching are no different in Japanese than in English. There is nothing specific to language or grammar in the Icon string and pattern matching repertoire. Of course, when the character set changes the actual code needs to change... 4. Let's look at the current situation for mixed-character sets. I am not sure how Chinese Icon stands on these, but consider plain-old Windows Icon. Divide functionality as follows: non-alphabetic output: Windows Icon already can do this non-alphabetic input: we have known bugs in the input processing of these, either in Windows Icon or the IPL "vidgets" code. non-alphabetic string scanning: not supported, but could be implemented as Icon Program Library procedures. Even Unicode string semantics could be implemented as library procedures on top of (even length!) Icon strings. We don't really need much additional infrastructure. Some folks in the user community could coordinate the library procedures to do this as an interesting project. We do also need someone who can compile Icon from its C code and debug I/O problems on a non-alphabetic platform at this point. -- Clint Jeffery, jeffery@cs.utsa.edu Division of Computer Science, The University of Texas at San Antonio Research http://www.cs.utsa.edu/research/plss.html From icon-group-sender Thu Sep 10 16:56:49 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id QAA04970 for ; Thu, 10 Sep 1998 16:56:48 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA31454; Thu, 10 Sep 1998 16:56:21 -0700 Date: Fri, 11 Sep 1998 08:56:14 +1200 (NZST) From: "Richard A. O'Keefe" Message-Id: <199809102056.IAA16557@atlas.otago.ac.nz> To: gep2@computek.net, icon-group@optima.CS.Arizona.EDU Subject: Re: Unicode support or support for non-Ascii based character manipulation? Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Gordon Peterson (http://www.computek.net/public/gep2/) wrote: Okay, I don't dispute that this move is happening but personally I still don't very much like it. The fact is that (at least here in the Western Hemisphere, where probably most of the world's computers are used) an eight-bit byte is already quite sufficient for most purposes, and doubling it comes at a cost in complexity and storage (RAM, disk, tape, whatever) which is simply very, very hard to justify on any genuine economic basis. This is a fictitious problem. UNIX systems at least support UTF-8, which is a compression method described in ISO 10646 and the Unicode book that has the property that ASCII characters *still* occupy exactly one byte each. When I use getwc() on this system, it decodes UTF-8 files and gives me ISO 10646 wide characters internally. If other countries have more difficult (or huge) character sets, that is (while a fact of life) simply an inherent disadvantage of their culture (and note that I'm not intending that as a slam or value judgement, it just IS the way it is), and I don't see a terribly convincing argument why the other countries (without that disadvantage) ought to pay the price too, just in order to artificially level the playing field. Many people _within_ Weestern Europe do not have the luxury of dealing with only a single language. I cannot write my father's name in ASCII, nor my sister-in-law's. Both of them are (in my father's case, were) monoglot Anglophones born into monoglot Anglophone families in an English-speaking country. I _can_ write their names in ISO Latin-1, but I _can't_ write half of the place-names of this country! (The officially approved orthography for Maori puts a macron over long vowels, like the 'a' in Maori. There are no macrons in Latin-1.) Even if my text switched between Latin-1 family members, I _still_ wouldn't be able to write English, because the inverted comma and and double inverted comma quotation marks are not available, let alone en dashes and em dashes. The *only* character set around in which this functionally-monoglot Anglophone can write *in English* about the people and places around him is ISO 10646; even Latin-1 just isn't good enough FOR ENGLISH! Note that ISO C, ISO C++ (which finally exists), and the world's first standard object-oriented language Ada95 all support wide characters. (You need the Technical Corrigenda for ISO C to get getwc() &co.), and that UNIX and Windows NT allow Unicode file names. I also note that Icon (like SNOBOL before it) has been of particular interest to scholars in the humanities, who would, for example, like to put Hebrew _and_ Arabic in the same document with English, which is something you can't do in any ISO 8859 family member, not without code switching, which is much harder to deal with than Unicode. There is the pretty obvious point that within Europe, they are going to *have* to use the new "Euro" sign. (Why have the Europeans named their new currency after an Australian mammal?) That's U+20AC, and if there's an 8-bit character set that has it, please tell us which. I can certainly understand and appreciate the problems that the huge character sets used in some eastern countries have played for them Never mind eastern countries. What about an American businessman writing to an office in Germany about their operations in Russia? What about a theologian writing in English but quoting Hebrew and Greek frequently? What about an English professor writing a book in modern English about Old English (we've lost four letters, which can be found in Unicode but not any 8-bit character set I know of. Ash _is_ in Latin1, but eth, thorn, yogh, and wynn are not.) > Has anyone thought about this yet? What does string and pattern matching mean in, for example, Japanese? The real problem is the equivalence one would expect between precomposed characters and base characters + floating diacriticals. That's _really_ proctalgic. By the way, 16 bits isn't enough; there are proposals already far advanced in the pipeline for characters to go into Plane 1. From icon-group-sender Thu Sep 10 16:57:31 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id QAA04991 for ; Thu, 10 Sep 1998 16:57:30 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA30366; Thu, 10 Sep 1998 16:57:03 -0700 Date: Thu, 10 Sep 1998 16:46:40 -0500 Message-Id: <199809102146.QAA01197@segfault.cs.utsa.edu> From: Clinton Jeffery To: gep2@computek.net Cc: icon-group@optima.CS.Arizona.EDU In-Reply-To: <199809101846.NAA18441@mail.cmpu.net> (gep2@computek.net) Subject: Re: Unicode support or support for non-Ascii based character manipulation? Reply-To: jeffery@cs.utsa.edu Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Gordon Peterson made a good point about a difficulty in building a Unicode version of Icon: > Another issue, perhaps unique to Icon, is the implementation of > "character set" datatypes, which I'd suspect would end up being quite > different for a language containing 65,536 distinct characters... This topic has come up before, and this is a point for which some infrastructure in the Icon implementation would be needed: minimally, we'd need to support "bit vectors" with more bits than csets' 256 bit limit, and in order to be practical we'd need to support sparse bit arrays so that most Unicode-supporting csets would not have to be an 8K object. I think these additions would not be very difficult to implement, but someone would have to spend some time to do them. I'm willing to supervise a student to do it, but we have to wait for a volunteer or else find some money to pay a student to do the work. :-) Clint Jeffery, jeffery@cs.utsa.edu Division of Computer Science, The University of Texas at San Antonio Research http://www.cs.utsa.edu/research/plss.html From icon-group-sender Fri Sep 11 08:22:13 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id IAA24299 for ; Fri, 11 Sep 1998 08:22:13 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA30712; Fri, 11 Sep 1998 08:21:46 -0700 Date: Thu, 10 Sep 1998 22:06:13 -0400 (EDT) From: cwills@bix.com Subject: RE: Context Switching To: icon-group@optima.CS.Arizona.EDU Message-Id: <9809102206.memo.65326@BIX.com> X-Cosy-To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO I believe that if one has access to a thread model, you could probably implement the coswitch function. By careful use of semaphors and blocking one could perform the switch. Under OS/2 the CSet (or VisualAge C compiler) one could use the _beginthread facility. The requirements would be: 1) all memory allocations from the OS have to be accessible from all threads 2) only one thread can be active at a time 3) any files (or other system objects) have to be shared across all threads Cheyenne From icon-group-sender Fri Sep 11 08:21:25 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id IAA24270 for ; Fri, 11 Sep 1998 08:21:24 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA31078; Fri, 11 Sep 1998 08:20:57 -0700 To: icon-group@optima.CS.Arizona.EDU Date: Fri, 11 Sep 1998 09:22:34 +0900 From: Eric Hildum Message-Id: <35F86D49.9BDF7813@Japan.NCR.COM> Organization: NCR Japan Sender: icon-group-request@optima.CS.Arizona.EDU References: <35F723CF.76B3CC97@Japan.NCR.COM>, <6t9b4o$8rs$1@ringer.cs.utsa.edu> Subject: Re: Unicode support or support for non-Ascii based character manipulation? Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Clinton Jeffery wrote: > Eric Hildum (Eric.Hildum@Japan.NCR.COM) wrote (and I paraphrase/edited): > : Icon ... supporting only ASCII makes it less useful for non-English language > : With Unicode... it should be possible to begin including support for > : non-English and non alphabetic languages. > > : Has anyone thought about this yet? What does string and pattern matching > : mean in, for example, Japanese? > > 1. Other folks have been thinking about it, especially Icon users in Asia. > For example, a Chinese version of Icon has been done by researchers in China. Glad to hear it. > > > 2. Going to Unicode might not be *that* difficult, but I think Unicode isn't > really as widely adopted as you might suggest. Many people seem to be using > mixed 8/16-bit strings. Windows NT, Macintosh, use Unicode. Unix is still EUC. > > > 3. The semantics of string and pattern matching are no different in Japanese > than in English. There is nothing specific to language or grammar in the Icon > string and pattern matching repertoire. Of course, when the character set > changes the actual code needs to change... That surprises me. Given the above comment about mixed 8/16 bit, I would expect you already would have run into the half width/full width character issue. How did you handle it? > > > 4. Let's look at the current situation for mixed-character sets. I am not > sure how Chinese Icon stands on these, but consider plain-old Windows Icon. > Divide functionality as follows: > non-alphabetic output: Windows Icon already can do this > non-alphabetic input: we have known bugs in the input processing > of these, either in Windows Icon or the IPL "vidgets" code. > non-alphabetic string scanning: not supported, but could be > implemented as Icon Program Library procedures. Even > Unicode string semantics could be implemented as library > procedures on top of (even length!) Icon strings. Chinese is probably the easiest double byte language to support. I don't think you have really considered or solved all the problems until you can support Japanese (for representation and manipulation) and Korean (for I/O). > > > We don't really need much additional infrastructure. Some folks in the user > community could coordinate the library procedures to do this as an > interesting project. We do also need someone who can compile Icon from its > C code and debug I/O problems on a non-alphabetic platform at this point. "non-alphabetic platform" hmmm, you haven't got any Chinese or Japanese grad students on the Icon project have you... > > > -- > Clint Jeffery, jeffery@cs.utsa.edu > Division of Computer Science, The University of Texas at San Antonio > Research http://www.cs.utsa.edu/research/plss.html -- --------------------------- Eric Hildum Eric.Hildum@Japan.NCR.COM From icon-group-sender Fri Sep 11 08:22:28 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id IAA24302 for ; Fri, 11 Sep 1998 08:22:28 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA31897; Fri, 11 Sep 1998 08:22:01 -0700 Date: Thu, 10 Sep 1998 20:32:54 -0500 (CDT) From: "John C. Paolillo" Message-Id: <199809110132.UAA02835@ling.uta.edu> To: gep2@computek.net, icon-group@optima.CS.Arizona.EDU Subject: Re: Unicode support or support for non-Ascii based character ma Cc: john@ling.uta.edu Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO gep2@computek.net wrote: >Okay, I don't dispute that this move is happening but personally I still don't >very much like it. The fact is that (at least here in the Western Hemisphere, >where probably most of the world's computers are used) an eight-bit byte is >already quite sufficient for most purposes, and doubling it comes at a cost in >complexity and storage (RAM, disk, tape, whatever) which is simply very, very >hard to justify on any genuine economic basis. If other countries have more >difficult (or huge) character sets, that is (while a fact of life) simply an >inherent disadvantage of their culture (and note that I'm not intending that as >a slam or value judgement, it just IS the way it is), and I don't see a terribly >convincing argument why the other countries (without that disadvantage) ought to >pay the price too, just in order to artificially level the playing field. This is a shockingly ignorant statement, from a social point of view, and although I realize that this list is meant for discussion of Icon, and not social issues or politics, as a sociolinguist who uses Icon in research on multilingualism online, I cannot let this statement go uncommented. Computer professionals on the whole show very little awareness that their decisions about how to implement technical standards within their fields are inherently valued. The propogation of standards also propogates the values that led to their selection. Moreover, when our purposes for a given standard change, we come to discover that what seemed advantageous at one point is no longer advantageous at another. This is exactly what has happened with ASCII (more than once) and now Unicode. When we allow ourselves to look beyond the technical aspects of technical standards, and look to see the social practices that the computer systems support, we see the same patterns. This is because the design and the use of standards are not simply technical practices, they are social practices and they only have any purpose in a social context. ASCII is a standard with an undeniable bias toward English. Even the representation and use of languages such as French (from which English at one time borrowed a large part of its lexicon) requires extraordinary means. Around the world, the number of English speakers is growing, while other languages are disappearing at a rate unprecedented in historic or prehistoric times. The fact that English is advancing, and the fact that so much computer technology is biased toward English, is not a value- neutral fact, as perceived by speakers of the thousands of languages who face the loss of the continuity of their cultures and histories, while simultaneously trying to adapt to a world that is changing in ways completely beyond their control. A decision to support Unicode, or something like it which allows for social and technical purposes other than those supported by ASCII, is a decision that is more sensitive to the values of other potential users. And this, I think, has been the major trend in computing of recent times; issues of ease of use, graphical interfaces, etc., have markedly broadened the social profile of the person who uses computers, and the social purposes to which they are put. Not that Unicode will save languages, or that computer professionals are responsible for the loss of languages, but rather that in a community of experts such as the Icon group, who have done so much to facilitate the study and use of other languages, the expression of a sentiment so singularly unsupportive of other languages seems incongruous. Respectfully, John C. Paolillo Linguistics Program University of Texas at Arlington From icon-group-sender Fri Sep 11 13:08:04 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id NAA07434 for ; Fri, 11 Sep 1998 13:08:04 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA31390; Fri, 11 Sep 1998 13:07:37 -0700 Message-Id: <4FD6422BE942D111908D00805F3158DF0757B57D@RED-MSG-52> From: Todd Proebsting To: "'cwills@bix.com'" , icon-group@optima.CS.Arizona.EDU Subject: RE: Context Switching Date: Fri, 11 Sep 1998 08:34:35 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Jcon (http://www.cs.arizona.edu/icon/jcon/) builds Icon co-expressions on top of Java's thread model. Just about any thread package would be sufficient---in fact, it's almost certainly overkill since (as implied below) exactly one thread is unblocked at any given time. Using semaphores it was quite simple. The requirements below are, indeed, necessary. Todd Proebsting -----Original Message----- From: cwills@bix.com [mailto:cwills@bix.com] Sent: Thursday, September 10, 1998 7:06 PM To: icon-group@optima.CS.Arizona.EDU Subject: RE: Context Switching I believe that if one has access to a thread model, you could probably implement the coswitch function. By careful use of semaphors and blocking one could perform the switch. Under OS/2 the CSet (or VisualAge C compiler) one could use the _beginthread facility. The requirements would be: 1) all memory allocations from the OS have to be accessible from all threads 2) only one thread can be active at a time 3) any files (or other system objects) have to be shared across all threads Cheyenne From icon-group-sender Fri Sep 11 13:08:35 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id NAA07439 for ; Fri, 11 Sep 1998 13:08:35 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA31741; Fri, 11 Sep 1998 13:08:08 -0700 Message-Id: <4FD6422BE942D111908D00805F3158DF0757B57E@RED-MSG-52> From: Todd Proebsting To: icon-group@optima.CS.Arizona.EDU Subject: RE: Unicode support or support for non-ASCII based character ma Date: Fri, 11 Sep 1998 08:44:01 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Jcon (http://www.cs.arizona.edu/icon/jcon) originally used Java's Unicode strings as the basis for implementing Icon strings. This was trivial to do, and we (Gregg Townsend and I) would have kept that implementation except that it was much too slow. I blame this in large part on the Java "String" implementation, and not on Unicode. (Although Unicode obviously wastes a lot of space in applications that are just using the ASCII subset.) Prior to switching to ASCII, we never faced the problem of what was the "right" thing to do with pre-defined csets with Unicode. For instance, what are the elements of the cset &ucase in an Unicode world? Todd Proebsting From icon-group-sender Fri Sep 11 13:09:21 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id NAA07475 for ; Fri, 11 Sep 1998 13:09:15 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA32575; Fri, 11 Sep 1998 13:08:48 -0700 To: icon-group@optima.CS.Arizona.EDU Date: 11 Sep 1998 11:18:47 -0700 From: Patrick Scheible Message-Id: Organization: ServNet Internet Services Sender: icon-group-request@optima.CS.Arizona.EDU References: <199809102056.IAA16557@atlas.otago.ac.nz> Subject: Re: Unicode support or support for non-Ascii based character manipulation? Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Gordon Peterson (http://www.computek.net/public/gep2/) wrote: > Okay, I don't dispute that this move is happening but personally I > still don't very much like it. The fact is that (at least here in the > Western Hemisphere, where probably most of the world's computers are > used) an eight-bit byte is already quite sufficient for most purposes, > and doubling it comes at a cost in complexity and storage (RAM, disk, > tape, whatever) which is simply very, very hard to justify on any > genuine economic basis. ASCII is also NOT adequate for many purposes even in the United States. Almost every word processor has their own incompatible way of representing diacritical marks and characters that were omitted from ASCII. (By the way, did you know that there are other countries in the Western Hemisphere besides the United States? And most of them don't speak English?) I work in a library, and libraries found plain ASCII inadequate all the way back in the early 1960s, when the computer programmers were still bitching about people who wanted lowercase letters. (By the way, the character set libraries adopted does a lot better job accomodating all the roman-alphabet languages than the later ISO standards; pre-composed characters with diacritical marks greatly expand the character set and still leave out some combinations that occure in Roman-alphabet languages.) There's borrowed words with diacritical marks, place names from foreign languages, personal names, quotations from old English. That's not even counting other Roman-alphabet languages. > If other countries have more difficult (or huge) character sets, > that is (while a fact of life) simply an inherent disadvantage > of their culture (and note that I'm not intending that as a slam > or value judgement, it just IS the way it is), and I don't see a > terribly convincing argument why the other countries (without > that disadvantage) ought to pay the price too, just in order to > artificially level the playing field. Many of those non-Roman character sets are no more difficult than Roman. Cyrillic has enough letters to spell the major sounds in its languages, which you've got to admit is a plus. Greek, Hebrew, Arabic, and numerous other alphabets are no harder in themselves than the Roman. Part of what made them a pain to program was that most of the industry and national standards organizations all took it on themselves to make their own 8-bit encodings, so you had to look outside the character string to interpret the bytes in it. Even if you skip the Han character set parts of Unicode, Unicode is a huge blessing in that all the other alphabets have code points within Unicode. The United States is not an island. Closing our eyes and pretending that rest of the world doesn't exist and doesn't buy our software would be a bad idea even if it was possible. If you're concerned about efficiency, maybe you should worry about all the gratuitous graphics. Over uncompressed ASCII, compressed Unicode uses little to no more disk or tape space. Compressing and uncompressing strings adds some complexity, but you get some simplicity by not having to keep track of which character set you're in and switching back and forth between character sets within what is logically one string. -- Patrick Scheible From icon-group-sender Fri Sep 11 16:59:39 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id QAA24561 for ; Fri, 11 Sep 1998 16:59:38 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA00225; Fri, 11 Sep 1998 16:59:11 -0700 Date: Fri, 11 Sep 1998 17:25:18 -0500 Message-Id: <199809112225.RAA07906@segfault.cs.utsa.edu> From: Clinton Jeffery To: cwills@bix.com Cc: icon-group@optima.CS.Arizona.EDU In-Reply-To: <9809102206.memo.65326@BIX.com> (cwills@bix.com) Subject: Re: Context Switching Reply-To: jeffery@cs.utsa.edu Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Cheyenne Wills and Todd Proebsting recently pointed out (or confirmed) that co-expressions can relatively easily be built on top of threads. Has anyone implemented and compared the performance of co-expressions using a modern threads package to Icon's assembler context switch on the same platform? It would be interesting to know whether we might just switch over to threads wholesale, or whether they still have a significant performance cost because the synchronization and concurrency of threads are "overkill" for co-expressions. Clint Jeffery, jeffery@cs.utsa.edu Division of Computer Science, The University of Texas at San Antonio Research http://www.cs.utsa.edu/research/plss.html From icon-group-sender Fri Sep 11 16:59:45 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id QAA24565 for ; Fri, 11 Sep 1998 16:59:45 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA00219; Fri, 11 Sep 1998 16:59:18 -0700 Date: Fri, 11 Sep 1998 17:28:39 -0500 Message-Id: <199809112228.RAA07942@segfault.cs.utsa.edu> From: Clinton Jeffery To: toddpro@microsoft.com Cc: icon-group@optima.CS.Arizona.EDU In-Reply-To: <4FD6422BE942D111908D00805F3158DF0757B57E@RED-MSG-52> (message from Todd Proebsting on Fri, 11 Sep 1998 08:44:01 -0700) Subject: Re: Unicode support or support for non-ASCII based character ma Reply-To: jeffery@cs.utsa.edu Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO > Jcon (http://www.cs.arizona.edu/icon/jcon) originally used Java's > Unicode strings as the basis for implementing Icon strings. This was > trivial to do, and we (Gregg Townsend and I) would have kept that > implementation except that it was much too slow. Ya, Jcon ought to be an easy solution for people who want Unicode! If its trivial to do, I wonder if this is something that you could allow the user to configure in if they need Unicode and are willing to pay for it. Also, it may be that Java's Unicode performance will improve in the future. Clint, jeffery@cs.utsa.edu From icon-group-sender Mon Sep 14 08:22:30 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id IAA06186 for ; Mon, 14 Sep 1998 08:22:29 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA01505; Mon, 14 Sep 1998 08:22:02 -0700 Date: Fri, 11 Sep 1998 17:38:15 -0700 From: Gregg Townsend Message-Id: <9809120038.AA13184@hawk.CS.Arizona.EDU> To: icon-group Subject: Re: Unicode support or support for non-ASCII based character ma Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Using 16-bit characters in Jcon would be possible, and I don't think it would necessarily incur a huge performance penalty. What's hard is redesigning the Icon language to support Unicode. For example: -- In Unicode, there aren't just 26 lower-case letters, and they're not all contiguous. What should &lcase contain? How would this affect existing programs? -- How should output be handled? If a non-ASCII character is written, should it be encoded in UTF8? What about existing programs that write 8-bit ISO-Latin-1 characters and don't expect any such encoding? The design work is the hard part. --------------------------------------------------------------------------- Gregg Townsend Gould-Simpson Building gmt@cs.arizona.edu Staff Scientist 1040 E. 4th St. 32 13 45N 110 57 16W Dept. of Computer Science PO Box 210077 tel: +1 520 621 4325 The University of Arizona Tucson, AZ 85721-0077 fax: +1 520 621 4246 From icon-group-sender Mon Sep 14 08:24:11 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id IAA06348 for ; Mon, 14 Sep 1998 08:24:11 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA01625; Mon, 14 Sep 1998 08:23:43 -0700 From: gep2@computek.net Date: Sat, 12 Sep 1998 05:39:34 -0500 (CDT) Message-Id: <199809121039.FAA15753@mail.cmpu.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: Re: Unicode support or support for non-Ascii based character manipulation? To: icon-group@optima.CS.Arizona.EDU X-Mailer: SPRY Mail Version: 04.00.06.17 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Errors-To: icon-group-errors@optima.CS.Arizona.EDU Content-Transfer-Encoding: 7bit Status: RO > ASCII is also NOT adequate for many purposes even in the United States. Of course. Icon isn't the language of choice for writing device drivers, either. The point is not that it's not perfect FOR EVERYTHING, but that it's damned useful (and reasonably efficient) just as it is. If something has to be built ON TOP OF IT, then the person who needs those higher-level function has many of the tools needed to do that. You shouldn't force EVERYBODY to use the higher-level functions just because SOMEBODY, SOMEWHERE decides that they want them. > Almost every word processor has their own incompatible way of representing diacritical marks and characters that were omitted from ASCII. Sure. And there are all kinds of other details which are not readily represented by any simple character set customization, too (complex mathematical formulas, for example). I wouldn't insist on using TeX (or whatever) to produce my clients' invoices just because somebody needed that level of functionality for the particular stuff that THEY are doing. > (By the way, did you know that there are other countries in the Western Hemisphere besides the United States? And most of them don't speak English?) Don't be condescending. > I work in a library, and libraries found plain ASCII inadequate all the way back in the early 1960s, when the computer programmers were still bitching about people who wanted lowercase letters. It's already been pointed out in this thread that the 65536 unique characters allowed in Unicode aren't even universally agreed as being "enough" and there are already people jockeying to push for more. Personally, ASCII works plenty well enough that I am not eager to see (for example) my E-mail archives blossom to twice the disk space they already take up. I'm not eager to see Web pages take twice as long to download than they need to. One poster mentioned a compression scheme to allow them to be smaller than 2x, but that comes at added complexity (which isn't pretty either). >> If other countries have more difficult (or huge) character sets, > that is (while a fact of life) simply an inherent disadvantage > of their culture (and note that I'm not intending that as a slam > or value judgement, it just IS the way it is), and I don't see a > terribly convincing argument why the other countries (without > that disadvantage) ought to pay the price too, just in order to > artificially level the playing field. > Many of those non-Roman character sets are no more difficult than Roman. True enough, but supporting all of them simultanously is undeniably more difficult and complex (for example, mixing left-to-right and right-to-left languages on the same line is a major pain. So let's say for example that you're going to try to support English and Hebrew within a single string. Are you going to ask Icon's string scanning to scan the resulting mess in the "correct" way (i.e. left to right through the English part, then jumping to the right-end-beginning of the following Hebrew word, continuing to the left, then jumping across the Hebrew word to continue with the English word to its right? And are you going to ask programmers of high-level applications to design their programs so that these kinds of exceptions and special cases for exotic character sets all work within their applications? Frankly, I just don't think it's usually worth it. Sure, some people need such things. For them, there are special-purpose multilanguage word processors (Multi-Lingual Scholar, Nota Bene, and numerous others). And I still think Icon is as good or better than most other languages for writing applications that have to do weird stuff with character strings. But I don't really want to have to have all that paraphenalia around and imposing itself on me all the time. > The United States is not an island. Closing our eyes and pretending that rest of the world doesn't exist and doesn't buy our software would be a bad idea even if it was possible. That's fine, but we're also large enough that we can (and probably should) allow ourselves to benefit from the efficiency that our systems make possible (_where_ possible!) The companies I typically consult with certainly don't need Unicode to produce their accounting reports, nor for their invoicing or communications or other functions. It would be ridiculous to build those kind of back-office applications the same way (even using the same tools, probably) that one would build a program that had to handle sanskrit or Chinese or something. > If you're concerned about efficiency, maybe you should worry about all the gratuitous graphics. I talk about my attitude about such things at my Web site (see the FAQ). > Over uncompressed ASCII, compressed Unicode uses little to no more disk or tape space. Compressing and uncompressing strings adds some complexity, More than a little, I think. Frankly, I don't think that (for the great majority of users here) that added complexity comes with enough benefit to justify the hassle. > but you get some simplicity by not having to keep track of which character set you're in and switching back and forth between character sets within what is logically one string. Character sets are not by themselves enough (as I discuss above regarding character DIRECTION also changing within a string). Once you decide to support EVERYBODY's weird stuff in the basic system, you're starting down a very slippery slope, with the probability that you're STILL not going to please everybody... and that by trying, you end up pleasing NOBODY at all. Gordon Peterson http://www.computek.net/public/gep2/ Support the Anti-SPAM Amendment! Join at http://www.cauce.org/ From icon-group-sender Mon Sep 14 08:23:43 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id IAA06280 for ; Mon, 14 Sep 1998 08:23:42 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA01577; Mon, 14 Sep 1998 08:23:15 -0700 To: icon-group@optima.CS.Arizona.EDU Date: 12 Sep 1998 07:30:31 GMT From: MUSKB@luff.latrobe.edu.au (Bastin,kim) Message-Id: <6td7un$cpr$2@news.latrobe.edu.au> Organization: La Trobe University Sender: icon-group-request@optima.CS.Arizona.EDU References: <4FD6422BE942D111908D00805F3158DF0757B57E@RED-MSG-52> Subject: Re: Unicode support or support for non-ASCII based character ma Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Todd Proebsting (toddpro@microsoft.com) wrote: : Jcon (http://www.cs.arizona.edu/icon/jcon) originally used Java's Unicode : strings as the basis for implementing Icon strings. This was trivial to do, : and we (Gregg Townsend and I) would have kept that implementation except : that it was much too slow. I blame this in large part on the Java "String" : implementation, and not on Unicode. (Although Unicode obviously wastes a : lot of space in applications that are just using the ASCII subset.) : Prior to switching to ASCII, we never faced the problem of what was the : "right" thing to do with pre-defined csets with Unicode. For instance, what : are the elements of the cset &ucase in an Unicode world? : Todd Proebsting Icon's &ucase (A-Z) is based on the English alphabet. Other European languages would add @ADCG... etc. But it doesn't stop there. Whether you have upper vs lowercase at all depends on the alphabet. Not all alphabets have such a distinction. Some have other distinctions that are novel to users of the Roman alphabet. For example, Greek, Hebrew and Arabic have special 'final' forms of some characters (used at the end of a word). Kim Bastin From icon-group-sender Mon Sep 14 08:24:36 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id IAA06355 for ; Mon, 14 Sep 1998 08:24:35 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA01514; Mon, 14 Sep 1998 08:24:08 -0700 From: gep2@computek.net Date: Sat, 12 Sep 1998 14:19:41 -0500 (CDT) Message-Id: <199809121919.OAA18685@mail.cmpu.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: Re: Unicode support or support for non-Ascii based character manipulation? To: icon-group@optima.CS.Arizona.EDU X-Mailer: SPRY Mail Version: 04.00.06.17 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Errors-To: icon-group-errors@optima.CS.Arizona.EDU Content-Transfer-Encoding: 7bit Status: RO >> Okay, I don't dispute that this move is happening but personally I still don't very much like it. The fact is that (at least here in the Western Hemisphere, where probably most of the world's computers are used) an eight-bit byte is already quite sufficient for most purposes, and doubling it comes at a cost in complexity and storage (RAM, disk, tape, whatever) which is simply very, very hard to justify on any genuine economic basis. > This is a fictitious problem. Which? Most of the points there are not subject to dispute, at least for most of us here in the USA. a) That I don't very much like it? b) That most of the world's computers are used in the Western Hemisphere? c) That an eight-bit byte is quite sufficient HERE for most (I didn't say ALL) purposes? d) That doubling it to a sixteen-bit byte comes at a cost (I didn't say a HUGE cost, but it IS a cost) in complexity and storage? e) That such a cost is hard to justify (again, for MOST purposes, in particular for business and most typical home use) given the limited or only specialized need for a bunch of exotic characters that probably 95% of the Western world's PC users are likely to never use? > UNIX systems at least... ...which represent something like 4% of machines sold, and it looks like NT 5.0 will continue to erode corporate use of Unix... > ...support UTF-8, which is a compression method described in ISO 10646 and the Unicode book that has the property that ASCII characters *still* occupy exactly one byte each. Okay, but this still results in more complex file formats and the need for suitable compression and decompression routines, and/or the use of mixed-mode processing in handling strings and/or doubling storage requirements for such strings while they are in memory (and thus obsoleting a lot of existing tools, library routines, and other programming). We've already talked about some of the issues regarding Icon implementation, and while probably not insurmountable (indeed, I think that a fully Unicode-supporting Icon implementation... NOT to replace the normal one!!... might be a very popular tool among those people who for whatever reason decide to use Unicode.) > When I use getwc() on this system, it decodes UTF-8 files and gives me ISO 10646 wide characters internally. Which means I presume that those characters internally take twice the storage they would otherwise. Thus at a cost of storage, and with the disadvantage that (barring some kind of new machine architecture at least where there is a NATIVE 16-byte byte I suppose, without direct addressability to address increments smaller than that) programming must change to account for the fact that all bytes are now byte PAIRS and that alignment issues suddenly become of prime importance. >> If other countries have more difficult (or huge) character sets, that is (while a fact of life) simply an inherent disadvantage of their culture (and note that I'm not intending that as a slam or value judgement, it just IS the way it is), and I don't see a terribly convincing argument why the other countries (without that disadvantage) ought to pay the price too, just in order to artificially level the playing field. > Many people _within_ Weestern Europe do not have the luxury of dealing with only a single language. Sure, but I'll point out that the great majority of them (and here I'm talking about typical business and home users, I'm not talking about academic types who ABSOLUTELY have to have a whole assortment of Armenian, Sanskrit and other highly specialized fonts for their scholarly work) do rather okay with the systems they're presently using. > I cannot write my father's name in ASCII, nor my sister-in-law's. Both of them are (in my father's case, were) monoglot Anglophones born into monoglot Anglophone families in an English-speaking country. I _can_ write their names in ISO Latin-1, but I _can't_ write half of the place-names of this country! I note that you don't mention WHICH country you're talking about. Of course, I suppose I could buy an island somewhere and name it some new name using some bizarre alphabet, and then ask everyone in the world to adjust all their systems to support my new alphabet! When most immigrants came to the USA during the latter half of the previous century (and the first twenty or so years of this one) a LOT of them changed the spelling and writing of their names. Hey, I can't address a letter to Peking/Beijing/whatever from my computer these days using the *REAL* name of the city, spelling the name the way the local residents do, either. Even among Western countries, a Parisian sending a letter to London will usually address it as "Londres", and most Americans writing to a friend in Cologne, Germany will address it that way rather than "Koln" (yeah, I know that they put the double-dot over the "o" too). But you know something? All of those letters WILL be delivered just fine to the recipients in Beijing, London, or Cologne, because we NORMALLY deal (and generally reasonably well) with these differences of the way that different world peoples call each other's countries. Not just when the names are different, but also when the alphabets are different. I'm sure I could write a letter to someone in an Arab country using a Western, non-Arab alphabet and still get it delivered. Despite the fact that locally written letters are doubtless addressed in Arabic. The post office there can handle BOTH (and better, I'm sure, than the US post office could deal with a letter addressed to someone HERE in Arabic!). > (The officially approved orthography for Maori puts a macron over long vowels, like the 'a' in Maori. There are no macrons in Latin-1.) Even if my text switched between Latin-1 family members, I _still_ wouldn't be able to write English, because the inverted comma and and double inverted comma quotation marks are not available, let alone en dashes and em dashes. Frankly, I think the double quote and apostrophe work just fine for most people. So to say that you "can't write English" is fairly ridiculous. In fact, what will probably happen is that these archaic inconveniences will probably simply fade away, due precisely to the fact that they aren't widely supported and most people simply couldn't care less. > The *only* character set around in which this functionally-monoglot Anglophone can write *in English* about the people and places around him is ISO 10646; even Latin-1 just isn't good enough FOR ENGLISH! Frankly, I think that the great majority of your audience will probably do just fine with a "close approximation". My neighbor and wonderful friend in Paris was Russian (in fact, he's on this list... HI Vlad!) but he didn't seem to be terribly upset that he couldn't write his name there spelled using the Cyrillic characters he'd grown up with. What's important for most people is that they communicate successfully with the people that are important to them, and most of the time we do that pretty well. Frankly, if you told most Americans that they weren't writing proper English because they didn't use inverted commas and double inverted comma quotation marks, or properly use en dashes and em dashes, I suspect that they'd look at you with disbelief as if you were from Mars or something, and tell you to get a life. > I also note that Icon (like SNOBOL before it) has been of particular interest to scholars in the humanities, who would, for example, like to put Hebrew _and_ Arabic in the same document with English, which is something you can't do in any ISO 8859 family member, not without code switching, which is much harder to deal with than Unicode. Obviously scholars who worry about such issues have a variety of specialized word processors and other such software to deal with their multi-lingual, multi-alphabet requirements (and that's as it should be, probably). Again, as I've mentioned in other posts, there are a whole series of issues that go way beyond simply having enough characters in the character set.for "everyone's" characters to be there in direct, native mode. Some languages write right-to-left in horizontal rows (Hebrew for example), and some languages write top to bottom and then to the left in vertical rows (Japanese for instance). Trying to mix these styles in the same document and on the same line is complex at minimum and very frustrating for typical users (when using such word processors, the simple use of the left and right arrow keys to move the cursor certainly doesn't obey the "principle of least astonishment" as it's known to most of us!). > There is the pretty obvious point that within Europe, they are going to *have* to use the new "Euro" sign. (Why have the Europeans named their new currency after an Australian mammal?) That's U+20AC, and if there's an 8-bit character set that has it, please tell us which. You're being ridiculous, since OBVIOUSLY they have created a NEW character EXPRESSLY for the purpose of it being new. Clearly it's not part of *any* previously-existing character set. (For that matter, it wasn't part of Unicode EITHER before they created it and got it added). Even once the character is added officially to the CHARACTER SET, even that doesn't really begin to solve the problem. Because now you have to address the issue of how you're going to ENTER it (keyboard?), and how you're going to DISPLAY it. There are (at least!) tens of thousands of fonts out there, and *none* of them will have these newly-created characters in them. I'd hate to even think of a TrueType font for "all" of Unicode's characters. Let alone a full set of fonts for all the different type styles and variants. These fonts (for those of us that tend to collect a lot of them) take up too much space on hard disks as it is. >> I can certainly understand and appreciate the problems that the huge character sets used in some eastern countries have played for them > Never mind eastern countries. What about an American businessman writing to an office in Germany about their operations in Russia? Straw man. These communications take place just fine today, without using Cyrillic. > What about a theologian writing in English but quoting Hebrew and Greek frequently? That's of academic interest but (HIGHLY specialized) academic needs should NOT force businesses and typical home users to pay more to support the needs of a VERY small percentage (at least until you get REAL far away) of other users. > What about an English professor writing a book in modern English about Old English (we've lost four letters, which can be found in Unicode but not any 8-bit character set I know of. Ash _is_ in Latin1, but eth, thorn, yogh, and wynn are not.) Again, most of us could care less. He's (or she's) welcome to deal with that issue however they like. The current system has NOT precluded such scholarly research up to now, so I don't see why this is such a big issue all of a sudden. > By the way, 16 bits isn't enough; there are proposals already far advanced in the pipeline for characters to go into Plane 1. And that starts to get even more ridiculous. As I said, it's a slippery slope when you decide that everyone has to be able to support EVERYBODY else's needs, even when for most people they are TOTALLY IRRELEVANT. I would imagine that someone has even assigned "official" Unicode character assignments to Klingon characters! So are OTHER people going to start dreaming up their own weird alphabets and asking the rest of the world to jump through hoops supporting those, too? Frankly, I'm never going to need to read (OR WRITE!) Armenian. I'm even unlikely to read or write most Asian languages, or Hebrew, or numerous others which are important to many people SOMEWHERE on the globe. And frankly, I think most of my consulting clients' needs are served just fine by "normal" ASCII. It is ludicrous to expect them to put up with extra cost and complexity in their business to support something that they don't need, don't want, and in fact would have *no* use for whatsoever. People who DO have special requirements (and I'm not disputing that there ARE such persons) should, alternatively, EXPECT to deal with the extra costs and the additional hassles that their special needs demand. Gordon Peterson http://www.computek.net/public/gep2/ Support the Anti-SPAM Amendment! Join at http://www.cauce.org/ From icon-group-sender Mon Sep 14 08:25:04 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id IAA06371 for ; Mon, 14 Sep 1998 08:24:57 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA01650; Mon, 14 Sep 1998 08:24:29 -0700 From: gep2@computek.net Date: Sun, 13 Sep 1998 03:26:46 -0500 (CDT) Message-Id: <199809130826.DAA13954@mail.cmpu.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: Re: Unicode support or support for non-Ascii based character ma To: icon-group@optima.CS.Arizona.EDU, johnp@ling.uta.edu X-Mailer: SPRY Mail Version: 04.00.06.17 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Errors-To: icon-group-errors@optima.CS.Arizona.EDU Content-Transfer-Encoding: 7bit Status: RO >>... If other countries have more >difficult (or huge) character sets, that is (while a fact of life) simply an >inherent disadvantage of their culture (and note that I'm not intending that as >a slam or value judgement, it just IS the way it is), and I don't see a terribly convincing argument why the other countries (without that disadvantage) ought to pay the price too, just in order to artificially level the playing field. > This is a shockingly ignorant statement, from a social point of view, and although I realize that this list is meant for discussion of Icon, and not social issues or politics, as a sociolinguist who uses Icon in research on multilingualism online, I cannot let this statement go uncommented. Hey, I don't mind the discussion. Implementors often have to ask what features they will and won't add (for a whole variety of reasons). As a designer of operating systems, I believe sometimes it's as or more important what features you LEAVE OUT as what you put in. > Computer professionals on the whole show very little awareness that their decisions about how to implement technical standards within their fields are inherently valued. Oh, I don't know that they're so unaware of that. But it's largely irrelevant for the large portion of users. There's generally a job to do, limited time and resources, and the desire to do it as well as possible given those constraints. > ASCII is a standard with an undeniable bias toward English. This is hardly surprising... even given the name: American Standard Code for Information Interchange. It was never designed nor intended to be a worldwide standard for everybody. It was designed to meet American needs. In fact, it's generally been extended to come close enough to most people's requirements that it HAS BECOME a world standard of sorts, but that was not the concern in the beginning. > Even the representation and use of languages such as French (from which English at one time borrowed a large part of its lexicon) requires extraordinary means. Around the world, the number of English speakers is growing, while other languages are disappearing at a rate unprecedented in historic or prehistoric times. The rate may be different, but the fact is that languages have come and gone since long before there was ASCII. > The fact that English is advancing, and the fact that so much computer technology is biased toward English, is not a value- neutral fact, I don't know that anybody pretends it IS value-neutral, but the facts are simply the facts, and it's likely that some natural languages will survive and some will die (perhaps to be studied only for academic purposes). I am not convinced that it is the mission of the computer professionals to be concerned about (or actively work towards) social or cultural re-engineering. > as perceived by speakers of the thousands of languages who face the loss of the continuity of their cultures and histories, while simultaneously trying to adapt to a world that is changing in ways completely beyond their control. Extinction is probably rarely a pretty sight... it would be nice to discover somewhere a small breeding colony of dinosaurs or something. But again, I don't consider it my mission to keep them alive. In Brittany, the residents are working to reinstate the teaching of the Breton language, and there's a lot of ill will because the French aren't very enthusiastic about that. There will continue to be cultural festivals and such, put together by those determined to keep their cultural heritage alive, and that's probably as it should be. > A decision to support Unicode, or something like it which allows for social and technical purposes other than those supported by ASCII, Again, note that there *are* other methods which allow supporting extended characters (FOR THOSE TIMES THEY ARE NEEDED) *with* ASCII. These include code page switching, which I agree is complex and such, but so is dealing with an enormous alphabet!!! > is a decision that is more sensitive to the values of other potential users. I would probably never deny them the ability to program whatever they want for their computer. On the other hand, when what they want starts to impinge upon MY rights and costs, then I have a reason to become involved. :-) > Not that Unicode will save languages, or that computer professionals are responsible for the loss of languages, ...thank you... > ...but rather that in a community of experts such as the Icon group, who have done so much to facilitate the study and use of other languages, the expression of a sentiment so singularly unsupportive of other languages seems incongruous. I have pointed out here repeatedly that I think Icon is one of the nicest languages there is for doing the kind of complex manipulations that are involved in all sorts of processing of natural languages. I fully approve of its use for such purposes. But while we're talking about "sensitivity" and "support", how about the "insensitivity" of those academics who would casually force the great majority of quite typical users to jump through hoops just so the same implementation can also support another alphabet (or hundreds of other alphabets!), Sanskrit for example!? Sounds to me like THEY aren't considering the needs of the others, either! Gordon Peterson http://www.computek.net/public/gep2/ Support the Anti-SPAM Amendment! Join at http://www.cauce.org/ From icon-group-sender Mon Sep 14 08:26:34 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id IAA06704 for ; Mon, 14 Sep 1998 08:26:30 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA01721; Mon, 14 Sep 1998 08:26:01 -0700 To: icon-group@optima.CS.Arizona.EDU Date: Mon, 14 Sep 1998 20:07:05 +0900 From: Eric Hildum Message-Id: <35FCF8D8.D8CCE176@Japan.NCR.COM> Organization: NCR Japan Sender: icon-group-request@optima.CS.Arizona.EDU References: <35F723CF.76B3CC97@Japan.NCR.COM> Subject: Re: Unicode support or support for non-Ascii based character manipulation? Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Well, I see my posting has started a bit more discussion than has been happening in the past. I am glad to see it. Clinton, I hope you have gotten some good ideas for research proposals... Eric Hildum wrote: > Icon has been a very interesting language for string manipulation, > however, the limit of supporting only ASCII makes it less useful for > non-English language work. With the computer industry heading towards > Unicode support, it should be possible to begin including support for > non-English and non alphabetic languages. However, I suspect this would > like lead to the need to change or generalize the semantics of a number > of the string manipulation and character intrinsics. > > Has anyone thought about this yet? What does string and pattern matching > mean in, for example, Japanese? > > -- > --------------------------- > Eric Hildum > Eric.Hildum@Japan.NCR.COM -- --------------------------- Eric Hildum Eric.Hildum@Japan.NCR.COM From icon-group-sender Mon Sep 14 08:26:52 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id IAA06714 for ; Mon, 14 Sep 1998 08:26:50 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA32472; Mon, 14 Sep 1998 08:26:20 -0700 To: icon-group@optima.CS.Arizona.EDU Date: Mon, 14 Sep 1998 07:11:48 +0100 From: David Feustel Message-Id: <35FCB3A4.BF335B0C@ix.netcom.com> Organization: Slurp News Feeds Sender: icon-group-request@optima.CS.Arizona.EDU References: <199809112225.RAA07906@segfault.cs.utsa.edu> Subject: Re: Context Switching Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO I'd rather see the current version of Icon released in 2 parts - an Ansi-C compatible source code tree that could be compiled directly using an Ansi C compiler, and the rest (including the current co-routine switching mechanism) that would have to be manually ported to any new system. This reorganization ought to make porting Icon to new platforms easier. Clinton Jeffery wrote: > Cheyenne Wills and Todd Proebsting recently pointed out (or confirmed) > that co-expressions can relatively easily be built on top of threads. > > Has anyone implemented and compared the performance of co-expressions using > a modern threads package to Icon's assembler context switch on the same > platform? It would be interesting to know whether we might just switch over > to threads wholesale, or whether they still have a significant performance > cost because the synchronization and concurrency of threads are "overkill" > for co-expressions. > > Clint Jeffery, jeffery@cs.utsa.edu > Division of Computer Science, The University of Texas at San Antonio > Research http://www.cs.utsa.edu/research/plss.html -- David Feustel 219-483-1857 From icon-group-sender Mon Sep 14 12:36:13 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id MAA20475 for ; Mon, 14 Sep 1998 12:36:10 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA01374; Mon, 14 Sep 1998 12:35:42 -0700 Message-Id: <35FD3E12.56A4@gte.net> Date: Mon, 14 Sep 1998 11:02:26 -0500 From: MJE Reply-To: evans@gte.net Organization: None X-Mailer: Mozilla 3.01 (Win95; I) Mime-Version: 1.0 To: icon-group@optima.CS.Arizona.EDU Subject: Re: Context Switching References: <199809112225.RAA07906@segfault.cs.utsa.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Errors-To: icon-group-errors@optima.CS.Arizona.EDU Content-Transfer-Encoding: 7bit Status: RO Does it really require threads to do context switching? I can see the possibility, but it's not as though the context switching that happens in Icon requires a "whole separate executable," is it? I have written subroutines in C that use static local variables to remember their "current state," so that every time you call them, they remember what was going on at the last call, and just pick up from there. They work like charms. It seems to me something similar could happen in Icon without the complication of threads. Maybe I'm missing something fundamental about the purpose of context switching in Icon? I haven't been using the language all that long. Mark Clinton Jeffery wrote: > > Cheyenne Wills and Todd Proebsting recently pointed out (or confirmed) > that co-expressions can relatively easily be built on top of threads. > > Has anyone implemented and compared the performance of co-expressions using > a modern threads package to Icon's assembler context switch on the same > platform? It would be interesting to know whether we might just switch over > to threads wholesale, or whether they still have a significant performance > cost because the synchronization and concurrency of threads are "overkill" > for co-expressions. > > Clint Jeffery, jeffery@cs.utsa.edu > Division of Computer Science, The University of Texas at San Antonio > Research http://www.cs.utsa.edu/research/plss.html From icon-group-sender Tue Sep 15 09:00:17 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id JAA00801 for ; Tue, 15 Sep 1998 09:00:17 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA03129; Tue, 15 Sep 1998 08:59:49 -0700 Date: Mon, 14 Sep 1998 21:52:44 -0400 (EDT) From: cwills@bix.com Subject: RE: Context Switching To: icon-group@optima.CS.Arizona.EDU Message-Id: <9809142152.memo.74091@BIX.com> X-Cosy-To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Yes.. it really does require a seperate "thread" of execution. The coswitch routine (the assembler code used for doing the context switch) replaces the C stack frame with a different stack frame then re-invokes the interepreter code. Note that this is not a "whole seperate executable" but preserving the current dynamic set of variables while the co-routine is running. Also note that if you dig deep enough into co-processes (co-routines and co-expressions) you will find that this is what is really going on under the covers. The algorithm used by Icon expressed in a C-ish pseudeo code is: coswitch( old_cs, new_cs, first ) int *old_cs, *new_cs, first; { /* save SP, frame pointers, and other registers in old_cs */ if ( first == 0 ) { /* load sp from new_sp[0] and clear frame pointers */ interp( 0, 0 ); syserr( "interp() returned in coswitch" ); } else { /* load sp, frame pointers and other registers from new_cs */ } } --------- To implement the coswitch function using threads, one would have to locate where coswitch is called, change the allocation of the co-expression stack to a creation of a thread that immediately blocks on a semaphore defined in the co-expression block. Coswitch then would be passed the current co-expression's semaphore and the co-expression's semaphore to swap to, "post" the called semaphore and wait on the calling semaphore (if any of that makes sense). Taking this alittle further, one might want to have a "master" thread (the original thread created by the system) and then when &main is created create a new thread for &main. This would allow &main to be "destroyed" and still have the "master" thread always there. The master thread could be used as a syncronizer if for some reason the OS needed stuff created by a parent thread. If done correctly, co-expressions could actually be executed in parallel (have the master thread perform all memory allocations, GC, file, etc). Cheyenne From icon-group-sender Tue Sep 15 09:00:31 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id JAA00809 for ; Tue, 15 Sep 1998 09:00:30 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA03147; Tue, 15 Sep 1998 09:00:02 -0700 From: gep2@computek.net Date: Mon, 14 Sep 1998 23:15:51 -0500 (CDT) Message-Id: <199809150415.XAA12328@mail.cmpu.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: Re: Context Switching To: icon-group@optima.CS.Arizona.EDU X-Mailer: SPRY Mail Version: 04.00.06.17 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Errors-To: icon-group-errors@optima.CS.Arizona.EDU Content-Transfer-Encoding: 7bit Status: RO > Does it really require threads to do context switching? Well, MAYBE not, but that's probably one of the easier ways to implement them. > I can see the possibility, but it's not as though the context switching that happens in Icon requires a "whole separate executable," is it? It certainly would NOT _require_ a separate executable. > I have written subroutines in C that use static local variables to remember their "current state," so that every time you call them, they remember what was going on at the last call, and just pick up from there. They work like charms. > It seems to me something similar could happen in Icon without the complication of threads. > Maybe I'm missing something fundamental about the purpose of context switching in Icon? I haven't been using the language all that long. It's more complicated than one might imagine due to the fact (to name just one example) that a given routine can be entered recursively, and that there is no guarantee that the recursions (and returns) will all be properly nested. Gordon Peterson http://www.computek.net/public/gep2/ Support the Anti-SPAM Amendment! Join at http://www.cauce.org/ From icon-group-sender Tue Sep 15 12:29:41 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id MAA10444 for ; Tue, 15 Sep 1998 12:29:39 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA03607; Tue, 15 Sep 1998 12:29:11 -0700 Message-Id: <35FEA142.5CE0@gte.net> Date: Tue, 15 Sep 1998 12:17:54 -0500 From: MJE Reply-To: evans@gte.net Organization: None X-Mailer: Mozilla 3.01 (Win95; I) Mime-Version: 1.0 To: icon-group@optima.CS.Arizona.EDU Subject: Re: Context Switching References: <9809142152.memo.74091@BIX.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Errors-To: icon-group-errors@optima.CS.Arizona.EDU Content-Transfer-Encoding: 7bit Status: RO Thanks, but I think you missed my point. The hidden assumption here is that Icon function calls shall behave exactly like C function calls. I am trying to say that, with auxiliary data structures, the job might be done without threads. The Icon compiler could be made smart enough to know when a function involves co-expressions, and when it does, not to use "standard" stack frames that have to be swapped in and out, but some other kind of data structure (heap allocation) for the local variables. I understand that if you need to replace processor-level stack frames, then yes you need assembler code. I have done that myself in asynchronous drivers that return from deeply nested routines. My point is: maybe there's a better way to handle the context switching requirement than stack-swapping. There is no law that says Icon has to declare local variables internally in the same fashion as C, on the stack frame. Mark cwills@bix.com wrote: > > Yes.. it really does require a seperate "thread" of execution. The > coswitch routine (the assembler code used for doing the context switch) > replaces the C stack frame with a different stack frame then re-invokes > the interepreter code. Note that this is not a "whole seperate executable" > but preserving the current dynamic set of variables while the co-routine > is running. > > Also note that if you dig deep enough into co-processes (co-routines and > co-expressions) you will find that this is what is really going on under > the covers. > > The algorithm used by Icon expressed in a C-ish pseudeo code is: > > coswitch( old_cs, new_cs, first ) > int *old_cs, *new_cs, first; > { > /* save SP, frame pointers, and other registers in old_cs */ > if ( first == 0 ) > { > /* load sp from new_sp[0] and clear frame pointers */ > interp( 0, 0 ); > syserr( "interp() returned in coswitch" ); > } > else > { > /* load sp, frame pointers and other registers from new_cs */ > } > } > --------- > > To implement the coswitch function using threads, one would have > to locate where coswitch is called, change the allocation of the > co-expression stack to a creation of a thread that immediately blocks > on a semaphore defined in the co-expression block. > > Coswitch then would be passed the current co-expression's semaphore > and the co-expression's semaphore to swap to, "post" the called semaphore > and wait on the calling semaphore (if any of that makes sense). > > Taking this alittle further, one might want to have a "master" thread > (the original thread created by the system) and then when &main is created > create a new thread for &main. This would allow &main to be "destroyed" > and still have the "master" thread always there. The master thread could > be used as a syncronizer if for some reason the OS needed stuff created > by a parent thread. If done correctly, co-expressions could actually > be executed in parallel (have the master thread perform all memory > allocations, GC, file, etc). > > Cheyenne From icon-group-sender Tue Sep 15 12:29:49 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id MAA10461 for ; Tue, 15 Sep 1998 12:29:48 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA03651; Tue, 15 Sep 1998 12:29:19 -0700 X-Authentication-Warning: pluto.mscc.huji.ac.il: mslamm owned process doing -bs Date: Tue, 15 Sep 1998 20:25:07 +0200 (IST) From: Ehud Lamm To: cwills@bix.com Cc: icon-group@optima.CS.Arizona.EDU Subject: RE: Context Switching In-Reply-To: <9809142152.memo.74091@BIX.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO If I understand correctly we can say that co-routines are less powerfull than full multi-tasking but more powerful than simple static variables ala C. It is easy to show which construct can be implimented using which other construct. Ehud Lamm mslamm@pluto.mscc.huji.ac.il From icon-group-sender Tue Sep 15 16:24:34 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id QAA20524 for ; Tue, 15 Sep 1998 16:24:34 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA04079; Tue, 15 Sep 1998 16:24:06 -0700 Date: Tue, 15 Sep 1998 13:57:13 -0700 From: kwalker@sfo.harbinger.com (Ken Walker) Message-Id: <199809152057.NAA09001@varda.premenos.com> To: icon-group@optima.CS.Arizona.EDU Subject: Re: Context Switching Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Md5: e40PQ5o00F2bK6KMYoGfVg== Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Errors-To: icon-group-errors@optima.CS.Arizona.EDU Content-Transfer-Encoding: 7bit Status: RO > From evans@gte.net Tue Sep 15 12:45:59 1998 > > Thanks, but I think you missed my point. The hidden assumption here is > that Icon function calls shall behave exactly like C function calls. I > am trying to say that, with auxiliary data structures, the job might be > done without threads. That is a good point. On the other hand the Icon runtime system is currently written in C and makes use of the C stack. There can be "suspended" C frames on stack when a context switch occurs. The changes needed to perform a co-expression context switch without doing a C-level context switch would be significant in the interpreter and some of the runtime system might end up looking rather ugly. It would be even more work in the compiler; the compiler converts Icon code into C code. Would such a change be worth making it a little easier to port co-expressions? Ken Walker, kenneth.walker@sfo.harbinger.com Harbinger Coporation, Concord, Ca. 94520 From icon-group-sender Wed Sep 16 08:38:15 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id IAA21918 for ; Wed, 16 Sep 1998 08:38:12 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA03742; Wed, 16 Sep 1998 08:37:43 -0700 Message-Id: <35FF1A94.66F1@gte.net> Date: Tue, 15 Sep 1998 20:55:32 -0500 From: MJE Reply-To: evans@gte.net Organization: None X-Mailer: Mozilla 3.01 (Win95; I) Mime-Version: 1.0 To: icon-group@optima.CS.Arizona.EDU Subject: Re: Context Switching References: <199809152057.NAA09001@varda.premenos.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Errors-To: icon-group-errors@optima.CS.Arizona.EDU Content-Transfer-Encoding: 7bit Status: RO If you want a language that can do a lot more than C, then why rely all the time on C conventions, instead of making your own? Icon is wonderful with strings because the strings are not C strings, they are Icon objects. Analogy: Icon can be wonderful with stacks, because the stacks are not C stacks, but Icon stacks. Icon has complete control of how it handles functions, coexpressions, recursion, and so on, there is no mandatory requirement that they all be treated as C function calls. Icon doesn't have to put parameters on a stack, it can put them on the heap and "context-switch" by switching data pointers to blocks on the heap. You could implement several "stack" structures right on the heap, instead of relying on the system stack. Those heap-based stacks would handle all the issues involved in context-switching, without resorting to fancy thread systems. Built-in operators and functions can easily be rewritten to assume that their stack exists elsewhere. I.e., as C calls, they take no input parameters, but instead lookup a global pointer that gives them their current stack somewhere on the heap, then they take parameters from that. Or, rather than rewriting the builtins, you just wrap them with "handlers" that know about these things and put the right parameters into the standard C function calls. So, none of the built-ins change, but you add "handlers" to baby-sit them with respect to the switching stacks. The idea of "fooling" the Icon executable, and doing so in a way that is non-portable, assembler-based, and buggy, and that will break with every vendor's compiler release, is what I dislike. I just wanted to share these ideas. Maybe I haven't really knocked down your points, but that's OK, we share ideas here. Mark Ken Walker wrote: > > > From evans@gte.net Tue Sep 15 12:45:59 1998 > > > > Thanks, but I think you missed my point. The hidden assumption here is > > that Icon function calls shall behave exactly like C function calls. I > > am trying to say that, with auxiliary data structures, the job might be > > done without threads. > > That is a good point. On the other hand the Icon runtime system is > currently written in C and makes use of the C stack. There can be > "suspended" C frames on stack when a context switch occurs. The changes > needed to perform a co-expression context switch without doing a C-level > context switch would be significant in the interpreter and some of > the runtime system might end up looking rather ugly. It would be > even more work in the compiler; the compiler converts Icon code into > C code. Would such a change be worth making it a little easier to > port co-expressions? > > Ken Walker, kenneth.walker@sfo.harbinger.com > Harbinger Coporation, Concord, Ca. 94520 Clinton Jeffery wrote: > > Mark, > > > I think you missed my point. The hidden assumption here is that Icon > > function calls shall behave exactly like C function calls. I am trying to > > say that, with auxiliary data structures, the job might be done without > > threads. > > Co-expressions include the state of suspended built-in operators and > functions, which *are* implemented by C functions. If generators and > "suspend" were only allowed from Icon source code to Icon source code, > then I think you would be right about this, but since they include > suspended C functions, I am afraid we have to swap the C stack. > > Clint From icon-group-sender Wed Sep 16 12:36:10 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id MAA02192 for ; Wed, 16 Sep 1998 12:36:09 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA05198; Wed, 16 Sep 1998 12:35:41 -0700 Date: Wed, 16 Sep 1998 09:42:26 -0700 From: swampler@noao.edu (Steve Wampler) Subject: Re: Context Switching To: icon-group@optima.CS.Arizona.EDU Message-Id: In-Reply-To: <35FF1A94.66F1@gte.net> Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO MJE wrote: > If you want a language that can do a lot more than C, then why rely all > the time on C conventions, instead of making your own? Performance and effort. > Icon is wonderful with strings because the strings are not C strings, > they are Icon objects. Analogy: Icon can be wonderful with stacks, > because the stacks are not C stacks, but Icon stacks. True, but most hardware has pretty direct support of C-style stacks, unless you design very carefully, it's easy to lose performance when you adopt other approaches. > Icon has complete control of how it handles functions, coexpressions, > recursion, and so on, there is no mandatory requirement that they all be > treated as C function calls. Icon doesn't have to put parameters on a > stack, it can put them on the heap and "context-switch" by switching > data pointers to blocks on the heap. You could implement several > "stack" structures right on the heap, instead of relying on the system > stack. Unless thinks have changed a lot since co-expressions were originally implemented, this is already exactly how Icon implements co-expressions - multiple heap-based stacks. This is also why you see co-expression stack overflow related errors - heap-based stacks are difficult to implement w/o the hardware support given to the system stack. As an historical aside, the original co-expression implementation did not have this problem, but only because of hardware support for user stacks on the PDP-11 class machines - highly non-portable. > Those heap-based stacks would handle all the issues involved in > context-switching, without resorting to fancy thread systems. Agreed, but for the most part, heap-based stacks are (were?) how co-expressions are implemented - to get the rest of the functionality you (and most of the rest of us) would like is a *major* rewrite of the implementation, see below. > Built-in operators and functions can easily be rewritten to assume that > their stack exists elsewhere. I.e., as C calls, they take no input > parameters, but instead lookup a global pointer that gives them their > current stack somewhere on the heap, then they take parameters from > that. Well, you shouldn't think in terms of a stack at this point, you have a general call graph now - each context (function, etc.) would have a node in the call graph for each invocation instance. Using heap based stacks is what Icon has now, but usually implemented to be efficient by using C-style stack access conventions. The 'functionally correct' way to implement Icon would be to go to what could be called an object-based implementation - each context would exist as an object in the heap. It is very hard to implement this efficiently, however, and the original implementation represented a trade between portability and efficiency. > Or, rather than rewriting the builtins, you just wrap them with > "handlers" that know about these things and put the right parameters > into the standard C function calls. So, none of the built-ins change, > but you add "handlers" to baby-sit them with respect to the switching > stacks. > > The idea of "fooling" the Icon executable, and doing so in a way that is > non-portable, assembler-based, and buggy, and that will break with every > vendor's compiler release, is what I dislike. > > I just wanted to share these ideas. Maybe I haven't really knocked down > your points, but that's OK, we share ideas here. A *long* ago I thought about an object-based implementation for co-expressions (more precisely for *all* context switching in Icon (a function call is also a context switch)) - since that's really what is needed for this approach to work). Mark is correct, it can be made to work, but it isn't easy to implement both correctly and efficiently. Personally, I would enjoy seeing such an implementation of Icon - it would be an interesting experiment to watch. It would not be a trivial undertaking and I suspect the Icon-project has enough to do already, so someone else would probably have to take the initiative. -- Steve Wampler - swampler@gemini.edu [Gemini 8m Telescopes Project (under AURA)] The gods that smiled at your birth are now laughing openly. (Fortune Cookie) From icon-group-sender Wed Sep 16 12:36:40 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id MAA02205 for ; Wed, 16 Sep 1998 12:36:35 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA05188; Wed, 16 Sep 1998 12:36:06 -0700 X-Authentication-Warning: pluto.mscc.huji.ac.il: mslamm owned process doing -bs Date: Wed, 16 Sep 1998 20:06:17 +0200 (IST) From: Ehud Lamm To: MJE Cc: icon-group@optima.CS.Arizona.EDU Subject: Re: Context Switching In-Reply-To: <35FF1A94.66F1@gte.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO On Tue, 15 Sep 1998, MJE wrote: > The idea of "fooling" the Icon executable, and doing soin a way that is > non-portable, assembler-based, and buggy, and that will break with every > vendor's compiler release, is what I dislike. > With this I must agree. Compling for a VM is nice, because it alows you to abstract the behaviour implicit in the language. However the implimentation of the compiler, VM or any other component should be implimented in a clean a way as possible. If you code it in C make it good solid portable C. Moreover, if Icon provides mechanisms which transcend the expressive power of C, it is yet to be shown. Co-Expressions can be simulated with static varibales -even though it may be hard in the recursive case. If Icon needs a thread package - let's demand it of the underlying OS. If it requires something weacker - let's decide what and demand that from the OS or implimenation langauge (i.e. C). Ehud Lamm mslamm@pluto.mscc.huji.ac.il From icon-group-sender Wed Sep 16 16:47:20 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id QAA10673 for ; Wed, 16 Sep 1998 16:47:19 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA05641; Wed, 16 Sep 1998 16:46:51 -0700 Message-Id: <4FD6422BE942D111908D00805F3158DF0757B5AF@RED-MSG-52> From: Todd Proebsting To: icon-group@optima.CS.Arizona.EDU Subject: RE: Context Switching Date: Wed, 16 Sep 1998 13:16:15 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO The problem of implementing co-expressions is directly related to how the implementation handles generators. If generators use stack allocation AND they leave activation records on the stack at a co-expression invocation, then separate stacks are necessary for co-expressions. Otherwise, suspended activation records from different co-expressions could become interwoven, and that would spell disaster. The current Icon interpreter uses recursion for some generators. Because the interpreter is written in C, uses recursion, and leaves those activations on the stack at co-expression invocation, there is no getting around the need for separate stacks. The recursive interpreter model is quite elegant---getting rid of it to support co-expressions would be a giant pain. Jcon (http://www.cs.arizona.edu/icon/jcon/) does not use a recursive interpreter, but suspended procedures definitely live on the stack at co-expression invocations. Therefore, it also relies on a context-switching mechanism (Java threads) to maintain multiple stacks. If the underlying implementation language (e.g., C or Java) supports only stack allocation of activation records, then it would be necessary to make sure the stack is ALWAYS in the same configuration at co-expression activation to avoid the need for a context switch. This would be very painful in compiled code. In an interpreter it would be easier, but no fun. Todd Proebsting From icon-group-sender Wed Sep 16 16:47:34 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id QAA10682 for ; Wed, 16 Sep 1998 16:47:33 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA04920; Wed, 16 Sep 1998 16:47:05 -0700 Date: Wed, 16 Sep 1998 18:11:17 -0400 (EDT) From: cwills@bix.com Subject: RE: Context Switching To: icon-group@optima.CS.Arizona.EDU Message-Id: <9809161811.memo.79389@BIX.com> X-Cosy-To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO I think that the crux of the issue is that the current (and as far as I know only) implementation of Icon is what we currently have to work with. As such... the current implementation uses C as the underlying language in which the Icon runtime libraries are written in. Most of Icon actually runs within the runtime library itself, alot of data is saved on the C stack within many of the builtin functions that are generators (ie: find, upto, etc.) The way that these builtin generators are written is to re-invoke the interpreter recursively (adding another layer on to the C stack). So... within the current implementation of the Icon VM, the easiest and most efficient method to perform a co-expression switch is to perform a full context-switch by flipping the C runtime stack. Is this a *bad* thing to do.... not really... it turns out the this is a fairly efficient method of performing the stack switch. I've implemented the co-switch routine in two different architectures, and 4 different compilers, and I never had that much problem with co-switch (in fact I believe that the SAS C now has as part of its distributed runtime library for the IBM Mainframe C, a set of co-routine functions that perform the exact same context switch that happens with co-switch. One must also remember that you are talking about the Icon Virtual Machine implementation itself. If one steps back and takes a look at the I-Code instructions (the same thing as the "java byte code"), the details of context switching is left to the I-VM. I also suspect that if one digs deep enough into the Java VM implementations, one will find all sort of mean nasty and ugly things to tweak out that last bit of performance. If one where to redesign and reimplement the I-VM, (such as in JCON) then different facilities could be used. Cheyenne PS.... If you think that rswitch.asm is bad... just be glad that the good folks at the Icon Project re-wrote the interpreter around version 5.10, 6, or somewhere... in that implementation the Icon stack frame was inter-mixed with the C stack frame, the interperter loop was written in assembler, garbage collection routines knew how to traverse around the C stack frames and find the Icon stack frame portions. From icon-group-sender Wed Sep 16 16:46:55 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id QAA10662 for ; Wed, 16 Sep 1998 16:46:55 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA05606; Wed, 16 Sep 1998 16:46:26 -0700 To: icon-group@optima.CS.Arizona.EDU Date: 16 Sep 1998 15:27:22 -0400 From: richard@goon.stg.brown.edu (Richard L. Goerwitz III) Message-Id: <6tp3eq$buu@goon.stg.brown.edu> Organization: Brown University Scholarly Technology Group Sender: icon-group-request@optima.CS.Arizona.EDU References: <9809120038.AA13184@hawk.CS.Arizona.EDU> Subject: Re: Unicode support or support for non-ASCII based character ma Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Re Unicode, Gregg Townsend wrote: > -- In Unicode, there aren't just 26 lower-case letters, and > they're not all contiguous. What should &lcase contain? > How would this affect existing programs? It's funny that this issue has raised its ugly head again. I guess it was four or five years ago that I advocated moving to Unicode (the logic was that Icon was a good string processing language, and that it was kind of silly to confine it to an eight-bit universe). The problem with doing this back then was one of resources (the Icon Project was winding down, and graphics had become the main concern). Users had some good spats over Unicode, but ultimately nobody had any resources to bring it off - and some prominent members of the Icon community denied that Unicode would ever be- come a prominent standard (aside: sixteen-bit characters are now the default for NT; Java also works on the same assumption; and Unicode is the core format for XML, too). Anyway, aside from me annoying everyone with my Unicode "mantra" (as Clint called it once), the issue pretty much went away. To the questions you raised (re lowercase letters, affect on existing programs): The number of alphabets with case distinctions is finite, and in fact rather low (Latin, Greek, Coptic, Armenian, and Cyrillic). So you define everything (except specifically uppercase letters in these scripts) to be lowercase. Then you define everything (except specifically lowercase letters in these scripts) to be uppercase. Note that in some languages the number of lowercase letters ex- ceeds the number of uppercase letters (and the mappings are not one-to-one). But in most cases, reasonable equivalents can be conjured up. I'd be happy to contribute code, if it comes to that. As for how this would affect existing programs: Heavily. The assumption of Unicode characters really screws up everything. Not only do you have to worry about upper/lowercase mapping, but you also have to think about (as GT notes above) I/O. Some ideas: 0) data and character streams should be read using different functions 1) user should be permitted to select a (default) input format (e.g., ISO 8859-1, UTF-8, UTF-16, etc.) for character stream readers 2) user should be permitted to select a (default) output format (e.g., ISO 8859-1, UTF-8, UTF-16, etc.) for character stream writers 3) all internal strings must be represented as UCS-2 (or UCS-4, if you don't care about memory); you can't use UTF-8, because multi-byte variable-length characters are no good for any code that relies on fixed-width characters For most programs, the user would just select ISO 8859 as the default character input and output format. The whole thing is a mess, and my guess is that unless there is a new source of funding for Icon - and an effort to put in a ground-up rewrite - it would not be feasible to rearrange every- thing to support Unicode. If it does happen, I suspect that it will happen in a descendant language that incorporates fundamental features like networking. Two years ago or so I saw some excellent networking extensions to Icon posted here, incidentally. Seemed to me they gave Icon a fighting chance. What ever became of them? One other thing to think about: What will the PERL community so on the Unicode/XML front? Keep your eyes peeled. -- Richard Goerwitz PGP key fingerprint: C1 3E F4 23 7C 33 51 8D 3B 88 53 57 56 0D 38 A0 For more info (mail, phone, fax no.): finger richard@goon.stg.brown.edu From icon-group-sender Thu Sep 17 08:25:08 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id IAA08006 for ; Thu, 17 Sep 1998 08:25:07 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA06267; Thu, 17 Sep 1998 08:24:39 -0700 Message-Id: <4FD6422BE942D111908D00805F3158DF0757B5B3@RED-MSG-52> From: Todd Proebsting To: "'cwills@bix.com'" , icon-group@optima.CS.Arizona.EDU Subject: RE: Context Switching Date: Wed, 16 Sep 1998 16:56:57 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Jcon (http://www.cs.arizona.edu/icon/jcon/) is another implementation of Icon. (Its implementation is completely independent of the standard implementation. For instance, there is no I-VM in Jcon.) Todd -----Original Message----- From: cwills@bix.com [mailto:cwills@bix.com] Sent: Wednesday, September 16, 1998 3:11 PM To: icon-group@optima.CS.Arizona.EDU Subject: RE: Context Switching I think that the crux of the issue is that the current (and as far as I know only) implementation of Icon is what we currently have to work with. [....] If one where to redesign and reimplement the I-VM, (such as in JCON) then different facilities could be used. Cheyenne From icon-group-sender Thu Sep 17 12:33:59 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id MAA18750 for ; Thu, 17 Sep 1998 12:33:57 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA06376; Thu, 17 Sep 1998 12:33:28 -0700 To: icon-group@optima.CS.Arizona.EDU Date: Thu, 17 Sep 1998 10:58:59 -0400 From: Jerry Leichter Message-Id: <360123B3.31B8@smarts.com> Organization: System Management ARTS Sender: icon-group-request@optima.CS.Arizona.EDU References: <9809161811.memo.79389@BIX.com> Subject: Re: Context Switching Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO There's been a great deal of work on this general issue in the Lisp community. In modern Lisp's there's the notion of a closure, which is a function plus its execution context as an accessible object. A co- expression is the direct Icon analogue of a closure. (A generator is a restricted kind of co-expression which, because it is syntactically bound to a particular point in the program, can be implemented more efficiently.) Implementing closures efficiently is challenging. The "obvious" implementation discards the use of a stack: Function frames (which are closures) are allocated from the heap, and garbage-collected just like everything else. If F call's G, then G's frame contains a return pointer to F, so as long as G is around, F can't be discarded by the GC. If the actual use of the code is just function calling, then once F returns (implying that G has returned), F's frame is now garbage (the only pointer is from G's frame, and *that* is now garbage). In practice, this is too expensive to be practical. So real implementa- tions play games. For example, they might allocate frames on the stack and then copy them to the heap if one of a number of specialized calls - which can, in effect, produce a user-accessible pointer to the frame - are executed. A cleverer example does this analysis in the compiler, and allocates the frame on the stack or heap as required right at the beginning, avoiding the copy. Icon, in effect, uses this implementa- tion: The only way for a closure to be "captured" is by the use of a coexpression creation, and the compiler can always recognize those. The big difference is that Icon assumes that most things are stack-based, and produces efficient code on that assumption. In a more aggressive closure implementation, there's a stack pointer and a current closure pointer, and code never uses the stack pointer to *find* the current closure - it always uses the closure pointer, which may point into the stack or into the heap. There's even an interesting implementation technique - due to Henry Baker, and intended for Lisp compilers that produce C code - which uses the C stack, but in a total unconventional fashion: Function calls are done as always, *but they never return*. Instead, to "return", you restore the current closure (frame pointer) and PC from your caller, *but you don't pop the stack*. Of course, then your stack gets very large after a while. At that point, you garbage-collect it: What's on the stack is a whole bunch of stack frames, most of which are now "dead", with no pointers to them. You compact them out, sliding the still-live frames down, and continue. Lisp closures are much more general and powerful than Icon co- expressions (much less generators). What Icon got in returns was much more efficient implementations (especially for generators, which are comparable in cost to conventional function calls). That tradeoff may no longer be quite as necessary. -- Jerry From icon-group-sender Fri Sep 18 12:27:04 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id MAA04305 for ; Fri, 18 Sep 1998 12:27:01 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA06397; Fri, 18 Sep 1998 12:26:31 -0700 Date: Fri, 18 Sep 1998 08:28:16 -0700 From: kwalker@sfo.harbinger.com (Ken Walker) Message-Id: <199809181528.IAA12163@varda.premenos.com> To: icon-group@optima.CS.Arizona.EDU Subject: Re: Context Switching Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Md5: piSHa99ToHQDrGzhcFoaNA== Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Errors-To: icon-group-errors@optima.CS.Arizona.EDU Content-Transfer-Encoding: 7bit Status: RO > From leichter@smarts.com Thu Sep 17 12:45:44 1998 > > There's been a great deal of work on this general issue in the Lisp > community. In modern Lisp's there's the notion of a closure, which is a > function plus its execution context as an accessible object. A co- > expression is the direct Icon analogue of a closure. (A generator is a > restricted kind of co-expression which, because it is syntactically > bound to a particular point in the program, can be implemented more > efficiently. I thought that the execution context for a Lisp closure was just data values. Does it also include an execution point so that you can continue a closure were it's last call left off? Ken Walker, kenneth.walker@sfo.harbinger.com Harbinger Coporation, Concord, Ca. 94520 From icon-group-sender Mon Sep 21 09:13:48 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id JAA22923 for ; Mon, 21 Sep 1998 09:13:41 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA10076; Mon, 21 Sep 1998 09:13:11 -0700 Sender: root@sulaco.novagate.net Message-Id: <3605928D.60089F5B@novagate.com> Date: Sun, 20 Sep 1998 19:41:02 -0400 From: Douglas Nichols X-Mailer: Mozilla 4.06 [en] (X11; I; Linux 2.0.35 i586) Mime-Version: 1.0 To: icon-group@optima.CS.Arizona.EDU Subject: Novice Question: File list in list box Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Errors-To: icon-group-errors@optima.CS.Arizona.EDU Content-Transfer-Encoding: 7bit Status: RO I have just started writing my first program in Icon. I am having difficulty understanding how to produce a list of files (those with the .jpg extension) in a directory which I can put in a list box with the VSetItems command so that the user can select the images to be batch processed. I would appreciate any help with this learning experience. Thank you. (I am developing it in Linux, but it will eventually have to run in Windows) From icon-group-sender Mon Sep 21 09:13:29 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id JAA22911 for ; Mon, 21 Sep 1998 09:13:27 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA10039; Mon, 21 Sep 1998 09:12:57 -0700 Date: Sun, 20 Sep 1998 00:47:43 -0500 (CDT) From: "John C. Paolillo" Message-Id: <199809200547.AAA14590@ling.uta.edu> To: icon-group@optima.CS.Arizona.EDU Subject: Icon 9.3 on Mk Linux? Cc: john@ling.uta.edu Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Dear Icon-folks -- Has anyone out there done a build of Icon on Mk Linux? This is the Linux that Apple sponsored which runs on PowerMacs. A version of Mk Linux also runs on Intel machines. I'm hoping to be able to use Icon on a PowerMac running Linux, and I'm wondering if anyone can suggest things I might need to watch for when attempting to build Icon under this or other variant flavors of Linux. Thanks in advance, John Paolillo UTA Linguistics From icon-group-sender Tue Sep 22 08:11:45 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id IAA09516 for ; Tue, 22 Sep 1998 08:11:45 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA10292; Tue, 22 Sep 1998 08:11:15 -0700 To: icon-group@optima.CS.Arizona.EDU Date: 22 Sep 1998 00:56:42 GMT From: Douglas Nichols Message-Id: <6u6ska$e32$0@205.138.136.103> Sender: icon-group-request@optima.CS.Arizona.EDU References: <6u4cgj$dhm$0@205.138.136.164> Subject: Re: Novice Question: how to fill a text box with a directory listing Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO I think I might a little closer to a solution, at least in Linux. I might be able to do something with open("ls *.jpg", "p") but I'm not sure what I will do when I port over to Windows. Is there a description anywhere of the differences between Icon under Linux and Windows? From icon-group-sender Tue Sep 22 16:42:02 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id QAA05134 for ; Tue, 22 Sep 1998 16:42:01 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA12114; Tue, 22 Sep 1998 16:41:32 -0700 To: icon-group@optima.CS.Arizona.EDU Date: 22 Sep 1998 19:17:32 GMT From: Douglas Nichols Message-Id: <6u8t4c$h7f$0@205.138.136.110> Sender: icon-group-request@optima.CS.Arizona.EDU References: <6u4cgj$dhm$0@205.138.136.164> Subject: Re: Novice Question: how to fill a text box with a directory listing Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO For the curious, my Linux solution is currently: chdir("/opt/oshs/progs/in") dir := open("ls *.jpg", "p") pictlist := [] while put(pictlist, read(dir)) VSetItems(vidgets["list1"], pictlist) What I will do in Windows remains to be seen. Thanks to all (both of you--I won't list you here to protect you from spam) who have taken the time to help me Btw, feel free to suggest corrections or stylistic improvements. Thank you. From icon-group-sender Wed Sep 23 12:28:05 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id MAA15462 for ; Wed, 23 Sep 1998 12:28:04 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA11839; Wed, 23 Sep 1998 12:27:35 -0700 To: icon-group@optima.CS.Arizona.EDU Date: Wed, 23 Sep 1998 17:16:05 GMT From: neitzel@gaertner.de (Martin Neitzel) Message-Id: Organization: Gaertner Datensysteme, Braunschweig, Germany Sender: icon-group-request@optima.CS.Arizona.EDU References: <6u4cgj$dhm$0@205.138.136.164>, <6u8t4c$h7f$0@205.138.136.110> Subject: Re: Novice Question: how to fill a text box with a directory listing Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO > chdir("/opt/oshs/progs/in") > dir := open("ls *.jpg", "p") > [...] > while put(pictlist, read(dir)) Works probably great now but might fail next February. The shell has to expand "ls *.jpg" and when your collection of pictures grows too big the limited command line buffer will overflow. A better programmatic interface would be: > dir := open ("find /opt/oshs/progs/in -name '*.jpg'", "p") See the manual page for find(1) if you need to restrict the search to just the first directory level and zillions of other paraphernalia. The important point is that the rest remains as is: read(dir) will return the filenames. Depending on how you invoke "find", you have to strip the pathname away, but hey, piecocake in Icon. Caveat: My Icon is way too rusty to say whether it provides something special for searching files without a separate process. Martin Neitzel From icon-group-sender Thu Sep 24 08:18:00 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id IAA23890 for ; Thu, 24 Sep 1998 08:17:58 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA14178; Thu, 24 Sep 1998 08:17:28 -0700 To: icon-group@optima.CS.Arizona.EDU Date: Wed, 23 Sep 1998 23:38:44 -0400 From: "Steve Hite" Message-Id: <6ucfk5$fh7@news.southeast.net> Organization: Southeast Network Services, Inc. Sender: icon-group-request@optima.CS.Arizona.EDU Subject: Possible to return a record from a loadable C func? Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO I've been looking at the cfuncs directory in Icon 9.3 for examples of how to create external C functions which can be dynamically loaded by the interpreter. I would like to construct a C function and have it return an Icon record type. Is this possible? Todd Proebstring...help! ;-) From icon-group-sender Thu Sep 24 12:40:55 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id MAA05492 for ; Thu, 24 Sep 1998 12:40:55 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA13283; Thu, 24 Sep 1998 12:40:25 -0700 To: icon-group@optima.CS.Arizona.EDU Date: 24 Sep 1998 09:19:02 -0700 From: gmt@optima.CS.Arizona.EDU (Gregg Townsend) Message-Id: <6udrdm$p2g@hawk.CS.Arizona.EDU> Organization: University of Arizona CS Department, Tucson AZ Sender: icon-group-request@optima.CS.Arizona.EDU References: <6ucfk5$fh7@news.southeast.net> Subject: Re: Possible to return a record from a loadable C func? Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Steve Hite wrote: > I've been looking at the cfuncs directory in Icon 9.3 for examples of how to > create external C functions which can be dynamically loaded by the > interpreter. I would like to construct a C function and have it return an > Icon record type. Is this possible? You can probably build a record if you can get the Icon caller to pass in a record constructor. There's no predefined macro for building records, as you've noticed, so it will take some digging in the Icon runtime system source code to figure out what to do. Creating a *new* record type that doesn't already exist is not feasible; all record types must be known at link time, where they affect tables and operands in the generated icode. --------------------------------------------------------------------------- Gregg Townsend Gould-Simpson Building gmt@cs.arizona.edu Staff Scientist 1040 E. 4th St. 32 13 45N 110 57 16W Dept. of Computer Science PO Box 210077 tel: +1 520 621 4325 The University of Arizona Tucson, AZ 85721-0077 fax: +1 520 621 4246 From icon-group-sender Thu Sep 24 12:40:54 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id MAA05489 for ; Thu, 24 Sep 1998 12:40:53 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA14447; Thu, 24 Sep 1998 12:40:17 -0700 Message-Id: <4FD6422BE942D111908D00805F3158DF0757B5DF@RED-MSG-52> From: Todd Proebsting To: "'Steve Hite'" , icon-group@optima.CS.Arizona.EDU Subject: RE: Possible to return a record from a loadable C func? Date: Thu, 24 Sep 1998 09:43:38 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO I wish I could help you, but I don't know beans about the implementation of Icon 9.3. (Jcon, http://www.cs.arizona.edu/icon/jcon, is my cup of tea.) Todd Proebsting -----Original Message----- From: Steve Hite [mailto:sch@southeast.net] Sent: Wednesday, September 23, 1998 8:39 PM To: icon-group@optima.CS.Arizona.EDU Subject: Possible to return a record from a loadable C func? I've been looking at the cfuncs directory in Icon 9.3 for examples of how to create external C functions which can be dynamically loaded by the interpreter. I would like to construct a C function and have it return an Icon record type. Is this possible? Todd Proebstring...help! ;-) From icon-group-sender Thu Sep 24 12:40:48 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id MAA05485 for ; Thu, 24 Sep 1998 12:40:42 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA14498; Thu, 24 Sep 1998 12:40:09 -0700 Date: Thu, 24 Sep 1998 08:43:34 -0700 From: swampler@noao.edu (Steve Wampler) Subject: Re: Possible to return a record from a loadable C func? To: sch@southeast.net Cc: icon-group@optima.CS.Arizona.EDU Message-Id: In-Reply-To: <6ucfk5$fh7@news.southeast.net> Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Hi Todd - Writing a C function to return an Icon record type is possible (*anything* is possible), but not easy. If the record is defined somewhere in the Icon code, it gets a little easier, as the run-time system will know about the constructor. Is that how you intend to use it, or were you thinking about being able to return a record whose definition is unknown to Icon before the C function is called? If it's the 'simpler' of the two cases, have you written C functions that return other Icon values (non-records) before? How about that return an aggragrete (set/table/list)? I suspect you will much better off if you've done both of these already, as most of the fundamental operations will be familar to you and you can concentrate on the record-specific stuff... I've never done what you need, so cannot offer anything concrete, but the basic steps would be: (1) call the record constructor to allocate storage for the record (you will probably have to wade through a fair amount of the runtime source code to see how to do this...). The record constructor routine will handle most of the tough stuff for you. (2) fill in the fields with Icon values (3) return the record using the C-to-Icon function return support. Sorry this is so vague! If you want to *define* the record type (i.e. there is no "record" expression for that type in the Icon code), you're on your own - that strikes me a *much* harder problem. -- Steve Wampler - swampler@gemini.edu [Gemini 8m Telescopes Project (under AURA)] The gods that smiled at your birth are now laughing openly. (Fortune Cookie) From icon-group-sender Mon Sep 28 11:15:01 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id LAA01482 for ; Mon, 28 Sep 1998 11:15:01 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA17338; Mon, 28 Sep 1998 11:14:30 -0700 Date: Fri, 25 Sep 1998 23:42:20 -0500 (CDT) From: "John C. Paolillo" Message-Id: <199809260442.XAA23265@ling.uta.edu> To: icon-group@optima.CS.Arizona.EDU Subject: Mk-Linux & Icon Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Dear all -- I requested info from anyone regarding building Icon under Mk-Linux (the PowerMac port of Linux sponsored by Apple) and got no response, so I assumed it hadn't been done, but might in principle be done. I figured I'd try it, just to see. Here is what I've done, and where I've gotten to: (i) I began by starting with the intel_linux config, figuring I may have to change things, but this might be closest. (ii) First problem: Mk-Linux doesn't seem to have the dlfcn.h header file anywhere; I found that this was required for LoadFuncs, so I had to remove that definition from define.h. (iii) After that things went along much further, until Second Problem: the context switch required for co-expressions for intel_linux is written in assembly language not understood under Mk-Linux (of course); I tried #define NoCoexpr in define.h, but the makefile still insisted on attempting to compile rswitch.s; I then fiddled common.hdr so that it looked for a copy of the file rswitch.c in config/unix/Common (which contains a "dummy context switch" definition), now the compiler complains that a function call there (I can't recall which one) doesn't match its definition. So far the results are promising, but I'm hung up on this business of getting the makefile to acknowledge that it doesn't need to compile in the co-expression context switch (or does it?). Perhaps I have things set up so that there is a conflicting definition somewhere? Any pointers anyone could give me would be appreciated. Thanks, John Paolillo UTA Linguistics From icon-group-sender Mon Sep 28 11:15:17 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id LAA01521 for ; Mon, 28 Sep 1998 11:15:17 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA17370; Mon, 28 Sep 1998 11:14:46 -0700 Message-Id: <01BDE98E.85A14B10@jm5-209.leading.net> From: Steve Hite To: "'icon-group@cs.arizona.edu'" Subject: Possible to call Windows DLLs from WinIcon? Date: Sat, 26 Sep 1998 20:44:54 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-Mime-Autoconverted: from quoted-printable to 8bit by baskerville.CS.Arizona.EDU id RAA09571 Errors-To: icon-group-errors@optima.CS.Arizona.EDU Content-Transfer-Encoding: 8bit Status: RO I see that there is an interface to call C routines in shared libraries on Unix systems using Icon 9.3.1. Has anyone explored calling C routines from Windows DLLs? Just thought I'd ask before taking on the task myself. Thanks, Steve P.S. As Steve Wampler has recently pointed out to me..."sure, *anything* is possible" ;-) From icon-group-sender Mon Sep 28 16:40:12 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id QAA11934 for ; Mon, 28 Sep 1998 16:40:12 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA17890; Mon, 28 Sep 1998 16:39:41 -0700 Message-Id: <2.2.32.19980928201230.00399958@pop5.ibm.net> X-Sender: usinet.laturk@pop5.ibm.net X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Sep 1998 15:12:30 -0500 To: icon-group@baskerville.CS.Arizona.EDU From: "Dr. Louis A. Turk" Subject: Writing Records to a File Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO I have a novice's question: How does one write or read a "record" to or from a file? When I try to do this I get an error message stating that a string or file was expected. If this is explained in the two books I have, I haven't been able to find it. I am trying to create a simple database to record progress of an exercise program. The records will be read to produce graphs. Thanks, Louis Turk From icon-group-sender Tue Sep 29 08:35:07 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id IAA04191 for ; Tue, 29 Sep 1998 08:35:06 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA18291; Tue, 29 Sep 1998 08:34:35 -0700 Date: Mon, 28 Sep 1998 21:22:45 -0500 (CDT) From: Chris Tenaglia To: "Dr. Louis A. Turk" Cc: icon-group@baskerville.CS.Arizona.EDU Subject: Re: Writing Records to a File In-Reply-To: <2.2.32.19980928201230.00399958@pop5.ibm.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Maybe I have the wrong impression, but Icon records seemed to me to be an extended data typing more than a database tool? For data I usually store it in CSV (comma delimited format) files. I index the key fields into Icon tables for quick access. Interfaces to commercial databases are a bit beyond me. Chris Tenaglia (system manager) | The future foretold, Medical College of Wisconsin | The past explained, 8701 W. Watertown Plank Rd. | The present largely appologized for. Milwaukee, WI 53226 (414)456-8765 | Organon to the Doctor On Mon, 28 Sep 1998, Dr. Louis A. Turk wrote: > Date: Mon, 28 Sep 1998 15:12:30 -0500 > From: "Dr. Louis A. Turk" > To: icon-group@baskerville.CS.Arizona.EDU > Subject: Writing Records to a File > > I have a novice's question: > > How does one write or read a "record" to or from a file? When I try to do > this I get an error message stating that a string or file was expected. If > this is explained in the two books I have, I haven't been able to find it. > > I am trying to create a simple database to record progress of an exercise > program. The records will be read to produce graphs. > > Thanks, > Louis Turk > > From icon-group-sender Tue Sep 29 16:43:59 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id QAA22657 for ; Tue, 29 Sep 1998 16:43:59 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA19058; Tue, 29 Sep 1998 16:43:28 -0700 Date: Tue, 29 Sep 1998 14:39:04 -0700 From: Gregg Townsend Message-Id: <9809292139.AA32746@hawk.CS.Arizona.EDU> To: icon-group@optima.CS.Arizona.EDU, johnp@ling.uta.edu Subject: Re: Mk-Linux & Icon Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO In general, you want to make configuration changes in a new directory config/unix/mklinux (or whatever you want to call it) and then run "make Configure" after any change. For the rswitch/Makefile problem, you probably need to remove rswitch.s from the mklinux configuration directory and copy in Common/rswitch.c. You should check out IPD238 (Configuring Icon) if you haven't already: http://www.cs.arizona.edu/icon/docs/ipd238.htm --------------------------------------------------------------------------- Gregg Townsend Gould-Simpson Building gmt@cs.arizona.edu Staff Scientist 1040 E. 4th St. 32 13 45N 110 57 16W Dept. of Computer Science PO Box 210077 tel: +1 520 621 4325 The University of Arizona Tucson, AZ 85721-0077 fax: +1 520 621 4246 From icon-group-sender Wed Sep 30 12:24:50 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id MAA24369 for ; Wed, 30 Sep 1998 12:24:50 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA19222; Wed, 30 Sep 1998 12:24:19 -0700 Message-Id: <199809301750.TAA28692@dom.vr.pl> From: "Woland" To: Subject: Iconc Date: Mon, 1 Jan 1996 17:34:28 +0100 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit X-Mime-Autoconverted: from quoted-printable to 8bit by baskerville.CS.Arizona.EDU id KAA21134 Errors-To: icon-group-errors@optima.CS.Arizona.EDU Content-Transfer-Encoding: 8bit Status: RO Hello !! My name is Piotr Drosd , I am a new Icon programmer , and I need a compiler iconc ( only binary version , a have no C compiler ) for Linux . Could you send me this file at free-time ? Thanks !! Piotr Drosd Technical University of Gdansk Faculty of Electrical and Control Engineering From icon-group-sender Wed Sep 30 16:21:54 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id QAA05189 for ; Wed, 30 Sep 1998 16:21:54 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA19207; Wed, 30 Sep 1998 16:21:22 -0700 Date: Wed, 30 Sep 1998 12:42:11 -0700 From: Gregg Townsend Message-Id: <9809301942.AA02967@hawk.CS.Arizona.EDU> To: icon-group, woland1@friko.sos.com.pl Subject: Re: Iconc Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO From: "Woland" I need a compiler iconc ( only binary version , a have no C compiler ) for Linux . Could you send me this file at free-time ? The iconc compiler is no longer supported or recommended. The interpreter is easier to use and usually fast enough even for production work. Binaries for Linux and other systems are available through the web page: http://www.cs.arizona.edu/icon/v93u.htm --------------------------------------------------------------------------- Gregg Townsend Gould-Simpson Building gmt@cs.arizona.edu Staff Scientist 1040 E. 4th St. 32 13 45N 110 57 16W Dept. of Computer Science PO Box 210077 tel: +1 520 621 4325 The University of Arizona Tucson, AZ 85721-0077 fax: +1 520 621 4246 From icon-group-sender Thu Oct 1 16:21:10 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id QAA03416 for ; Thu, 1 Oct 1998 16:21:09 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA19680; Thu, 1 Oct 1998 16:20:38 -0700 To: icon-group@optima.CS.Arizona.EDU Date: 1 Oct 1998 22:10:43 GMT From: espie@liafa.jussieu.fr (Marc Espie) Message-Id: <6v0ul3$3o9$1@vishnu.jussieu.fr> Organization: None Sender: icon-group-request@optima.CS.Arizona.EDU References: <9809301942.AA02967@hawk.CS.Arizona.EDU> Subject: Re: Iconc Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO In article <9809301942.AA02967@hawk.CS.Arizona.EDU>, Gregg Townsend wrote: > From: "Woland" > > I need a compiler iconc ( only binary version , a have no C compiler ) > for Linux . Could you send me this file at free-time ? >The iconc compiler is no longer supported or recommended. The interpreter >is easier to use and usually fast enough even for production work. I have a project which runs much faster (3 times) using the Icon compiler. Admittedly, the compilation is a behemoth, swallowing 90 Megs of memory, and taking more than an hour on a decent machine. Still... this is a shame there is not enough resource left for developping the compiler. It still does work, is reasonably reliable, and produce faster code. Granted, it's missing separate compilation, and it would be nice if the type analyzer could go all the way through and generate true C integer/floating point arithmetic, but it is a nice program... I'm currently integrating Icon to the set of ports available through OpenBSD. Considering that OpenBSD runs on 12 architectures, this means some work for checking that the coexpressions work. It will most certainly be in for 2.4, available in december. Once it's in, this means a very simple setup on a slew of machine. I'll keep you posted... -- Marc Espie |anime, sf, juggling, unicycle, acrobatics, comics... |AmigaOS, OpenBSD, C++, perl, Icon, PostScript... | `real programmers don't die, they just get out of beta' From icon-group-sender Tue Oct 13 06:38:05 1998 Return-Path: Received: from ursus.CS.Arizona.EDU (ursus.CS.Arizona.EDU [192.12.69.63]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id GAA05914 for ; Tue, 13 Oct 1998 06:38:04 -0700 (MST) Received: by ursus.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA06824; Tue, 13 Oct 1998 06:38:04 -0700 Date: Tue, 13 Oct 1998 09:44:48 +0300 (EEST) From: Kimmo Kettunen To: icon-group@optima.CS.Arizona.EDU Subject: A problem with sets Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Hello, I have a following of question. I am doing noun stem synthesis of Finnish with Icon. The program works fine, but due to Icon's nice capabilities I have been a bit sloppy with programming and can not quite figure out the way out of it. During the stem synthesis I have pretty many string variables which may be altered during the process. Part of the variables are unnecessary and redundant, and to prune the results I put them all in the end into a set structure to get rid of redundant ones. Works fine, results are OK. BUT: now I do not know excactly, which variables I get out of the set as I see only the results, string values of the variables. Can somebody tell me, how to get this information (I guess there is a way to do it, I just cant figure it out). Kimmo ******************************* Kimmo Kettunen kettunen@kaapeli.fi http://www.kaapeli.fi/~kettunen ******************************* From icon-group-sender Tue Oct 13 12:03:41 1998 Return-Path: Received: from ursus.CS.Arizona.EDU (ursus.CS.Arizona.EDU [192.12.69.63]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id MAA17629 for ; Tue, 13 Oct 1998 12:03:39 -0700 (MST) Received: by ursus.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA06959; Tue, 13 Oct 1998 12:03:39 -0700 Date: Tue, 13 Oct 1998 08:55:44 -0700 From: kwalker@sfo.harbinger.com (Ken Walker) Message-Id: <199810131555.IAA14201@varda.premenos.com> To: icon-group@optima.CS.Arizona.EDU Subject: Re: A problem with sets Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Md5: L/oU4NJMqzn8KoQZH9RneQ== Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Errors-To: icon-group-errors@optima.CS.Arizona.EDU Content-Transfer-Encoding: 7bit Status: RO I'm not sure I understand exactly what infomation you want to associate with the string values, but I would suggest using tables instead of sets. Use the string value as the table key and assign the assocaited information as the table entry. When you are done putting entries in the table, you end up with the last one for each key. You may want to make the assocated information a record. It may be convenient to make the string value one of the fields in the record. Ken Walker, kenneth.walker@sfo.harbinger.com Harbinger Coporation, Concord, Ca. 94520 > Date: Tue, 13 Oct 1998 09:44:48 +0300 (EEST) > From: Kimmo Kettunen > > I have a following of question. I am doing noun stem synthesis of > Finnish with Icon. The program works fine, but due to Icon's nice > capabilities I have been a bit sloppy with programming and can not quite > figure out the way out of it. > > During the stem synthesis I have pretty many string variables which may be > altered during the process. Part of the variables are unnecessary and > redundant, and to prune the results I put them all in the end into a set > structure to get rid of redundant ones. Works fine, results are OK. > > BUT: now I do not know excactly, which variables I get out of the set as I > see only the results, string values of the variables. > > Can somebody tell me, how to get this information (I guess there is a > way to do it, I just cant figure it out). From icon-group-sender Thu Oct 15 16:38:22 1998 Return-Path: Received: from ursus.CS.Arizona.EDU (ursus.CS.Arizona.EDU [192.12.69.63]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id QAA09516 for ; Thu, 15 Oct 1998 16:38:22 -0700 (MST) Received: by ursus.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA07726; Thu, 15 Oct 1998 16:38:21 -0700 Date: Thu, 15 Oct 1998 15:49:45 -0500 From: Kurt Welgehausen Message-Id: <199810152049.PAA12147@AbacusRT.com> To: icon-group@optima.CS.Arizona.EDU Subject: getch/Linux/Intel Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO In my X-term, the Alt key acts as a true Meta key, so characters are returned with the high bit set. getch() fails on any character with the high bit set, so it won't let me use the Alt key. I don't see anything in read_a_char that's causing failure, but I'm not very familiar with Icon source. I'd like to change Icon, not X-windows or X-term. read(), of course, gets meta characters just fine. Can anyone help me? Thanks, Kurt Welgehausen From icon-group-sender Sat Oct 17 09:18:43 1998 Return-Path: Received: from ursus.CS.Arizona.EDU (ursus.CS.Arizona.EDU [192.12.69.63]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id JAA11645 for ; Sat, 17 Oct 1998 09:18:43 -0700 (MST) Received: by ursus.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA08300; Sat, 17 Oct 1998 09:18:42 -0700 To: icon-group@optima.CS.Arizona.EDU Date: Fri, 16 Oct 1998 08:37:32 GMT From: r.raschke@quadstone.com (Robby) Message-Id: Organization: Quadstone Limited Sender: icon-group-request@optima.CS.Arizona.EDU References: Reply-To: r.raschke@quadstone.com Subject: Re: A problem with sets Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO In article , Kimmo Kettunen writes: > Hello, [...] > During the stem synthesis I have pretty many string variables which may be > altered during the process. Part of the variables are unnecessary and > redundant, and to prune the results I put them all in the end into a set > structure to get rid of redundant ones. Works fine, results are OK. > > BUT: now I do not know excactly, which variables I get out of the set as I > see only the results, string values of the variables. [...] > Kimmo > Hmm, you could use a table (aka associative array) instead. Say you have a bunch of variables a to z, you can build a table indexed by the variable values having the name of the variable as the associated value: mytable := table(0) mytable[a] := name(a) ... mytable[z] := name(z) Since indices are unique, you'll always end up with a string being associated with the last variable that contained the string that you added to the table, eg. if a and b contain the same string the value of mytable[a] and mytable[b] will be "b" after the above statements. variable("b") gets you back to the original variable, eg. variable(mytable[a]) = b I didn't test any of this. Robby From icon-group-sender Sat Oct 17 09:19:03 1998 Return-Path: Received: from ursus.CS.Arizona.EDU (ursus.CS.Arizona.EDU [192.12.69.63]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id JAA11648 for ; Sat, 17 Oct 1998 09:19:03 -0700 (MST) Received: by ursus.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA08301; Sat, 17 Oct 1998 09:19:03 -0700 Date: Fri, 16 Oct 1998 10:34:35 -0700 From: Gregg Townsend Message-Id: <9810161734.AA12630@hawk.CS.Arizona.EDU> To: icon-group@optima.CS.Arizona.EDU, kaw@AbacusRT.com Subject: Re: getch/Linux/Intel Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO From: Kurt Welgehausen ... getch() fails on any character with the high bit set... With the high bit set, the cast from char to int is returning a negative value, causing getch() to fail. Here's a patch for src/runtime/rlocal.r: *** rlocal.old Fri Oct 16 10:29:05 1998 --- rlocal.r Fri Oct 16 10:30:58 1998 *************** *** 1457,1463 **** } if (! status) return -1; ! else return (int)c; } /* --- 1457,1463 ---- } if (! status) return -1; ! else return c & 0xFF; } /* --------------------------------------------------------------------------- Gregg Townsend Gould-Simpson Building gmt@cs.arizona.edu Staff Scientist 1040 E. 4th St. 32 13 45N 110 57 16W Dept. of Computer Science PO Box 210077 tel: +1 520 621 4325 The University of Arizona Tucson, AZ 85721-0077 fax: +1 520 621 4246 From icon-group-sender Mon Oct 19 06:19:47 1998 Return-Path: Received: from ursus.CS.Arizona.EDU (ursus.CS.Arizona.EDU [192.12.69.63]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id GAA21266 for ; Mon, 19 Oct 1998 06:19:47 -0700 (MST) Received: by ursus.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA09027; Mon, 19 Oct 1998 06:19:46 -0700 Date: Mon, 19 Oct 1998 06:13:26 -0700 From: Ralph Griswold Message-Id: <9810191313.AA09479@jupiter.CS.Arizona.EDU> To: icon-group Subject: Icon FAQ Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Frequently Asked Questions About The Icon Programming Language Last updated October 12, 1998. This FAQ answers various questions about the Icon programming language, ranging from what it is to how you can get it. The master copy of this FAQ is the Web page http://www.cs.arizona.edu/icon/faq.htm. Other on-line documentation is available via the main Icon page at http://www.cs.arizona.edu/icon/. This FAQ is written by Ralph Griswold and Gregg Townsend, with help from Cliff Hathaway, Clint Jeffery, Bob Alexander, and Todd Proebsting. * 1. What is Icon? * 2. What is Icon good for? * 3. Where did Icon come from? * 4. What does "Icon" stand for? * 5. On what computers does Icon run? * 6. Who did all these implementations? * 7. Are there other implementations in the works? * 8. What about different versions of Icon? * 9. Which implementations of Icon have graphics/window capabilities? * 10. Where can I get Icon? * 11. Where can I get documentation about Icon? * 12. How do I get started with Icon? * 13. What is the Icon Project? * 14. Where can I find examples of Icon programs? * 15. What is Idol? * 16. How often is on-line material for Icon updated? * 17. How do I stay up to date with what's going on with Icon? * 18. Is there a users' group for Icon? * 19. How do I get technical support? * 20. What do I need to run Icon? * 21. Can I build my own implementation of Icon for a new platform? * 22. What is ProIcon? ------------------------------------------------------------------------ 1. What is Icon? Icon is a very high level general-purpose programming language with extensive features for processing strings (text) and data structures. Icon is an imperative, procedural language with a syntax that is reminiscent of C and Pascal, but its semantics are at a much higher level than those languages. Icon has a novel expression-evaluation mechanism that integrates goal-directed evaluation and backtracking with conventional control structures. It has a string scanning facility for pattern matching that avoids the tedious details usually associated with analyzing strings. Icon's built-in data structures include sets and tables with associative lookup, lists that can be used as vectors or stacks and queues, and records. Icon is a strongly, though not statically, typed language. It provides transparent automatic type conversion. For example, if an integer is used in an operation that requires a string, the integer is automatically converted to a string. Several implementations of Icon have high-level graphics facilities with an easily programmed window interface. Icon manages storage automatically. Objects are created as needed during program execution and space is reclaimed by garbage collection as needed. The sizes of strings and data structures are limited only by the amount of available memory. 2. What is Icon good for? As a general-purpose programming language with a large computational repertoire, Icon can be used for most programming tasks. It's at its best when used build software tools, for processing text, and when ease of programming is needed for experimental and research applications. Paradoxically, Icon is used most often for short, one-shot tasks and for very complex applications. Icon is designed to make programming easy; it emphasizes the value of programmer's time and the importance of getting programs to work quickly. This explains its usefulness for prototyping as well as the apparent paradox of applicability to simple and complex applications. 3. Where did Icon come from? Icon is the latest in a series of high-level programming languages designed to facilitate programming tasks involving strings and structures. The original language, SNOBOL, was developed at Bell Telephone Laboratories in the early 60s. SNOBOL evolved into SNOBOL4, which is still in use. Subsequent languages were developed at The University of Arizona with support from the National Science Foundation. Incidentally, Icon bears little physical resemblance to SNOBOL4, although it has similar objectives and many similar capabilities. 4. What does "Icon" stand for? The name Icon (which is not spelled ICON) is not an acronym nor does it stand for anything in particular, although the word "iconoclastic" was mentioned at the time the name was chosen. The name predates the now common use of "icon" to refer to small images used in graphical user interfaces. This latter usage sometimes causes persons to think mistakenly that Icon is designed to create or manipulate icons. There's not much that can be done about this. 5. On what computers does Icon run? The latest version, 9, runs on UNIX, MS-DOS, Windows 3.1, Windows 95, Windows NT, Macintosh/MPW, VAX/VMS, the Amiga, and the Acorn Archimedes. There are older versions for the Atari ST, IBM CMS and MVS, the Macintosh, and OS/2. Icon programs are highly portable. Most Icon programs can run on any platform that supports Icon. An exception is programs that use Icon's graphics facilities, which are not available on all platforms and vary somewhat among the platforms for which they are implemented. Jcon is a new Java-based implementation of the Icon programming language. The Jcon translator, written in Icon, generates Java class files that execute in conjunction with a run-time system written in Java. Jcon is an essentially complete implementation of Icon, including graphics and large integers. A few minor features are missing -- mostly things like chdir() that cannot be done in Java. Jcon-derived programs are not as fast as those using the standard Icon intepreter. 6. Who did all these implementations? The original implementation of Icon for UNIX was done at The University of Arizona. Most of the other implementations originally were done by volunteers scattered around the world. It's worth noting that all implementations of Icon are based on the same source code, which is written in C. This contributes to the portability of Icon itself, as well as to the portability of programs written in Icon. The implementation of Jcon was done at The University of Arizona by Todd Proebsting and Gregg Townsend, with contributions from Denise Todd and Bob Alexander. 7. Are there other implementations in the works? At the present time, Icon runs on most generally available platforms. Consequently implementation work currently is focused on improvements. When a new computer or operating system becomes popular, new Icon implementations typically follow. 8. What about different versions of Icon? Icon has evolved through a series of versions with improved and extended capabilities. The latest major version number is 9. This version includes recent changes and additions, notably in the graphics area, and runs on UNIX, MS-DOS, Macintosh/MPW, VAX/VMS, the Amiga, and Acorn Archimedes. Other implementations presently are at Version 8. Almost all programs that run under Version 8 and that do not use graphics will run under Version 9. 9. Which implementations of Icon have graphics/window capabilities? Icon's graphics facilities presently are supported on UNIX, VAX/VMS, Windows 3.1 (with Win32s), Windows 95, and Windows NT. 10. Where can I get Icon? Icon is available via anonymous FTP and on the Web. For FTP, use ftp.cs.arizona.edu and cd /icon. For the Web, use http://www.cs.arizona.edu/icon/ and check out the links there. For FTP, the directory /icon/binaries contains executable versions of Icon for several systems, including several popular UNIX platforms. The directory /icon/packages contains source code, test programs, related material, and, most cases, executable binaries as well. All directories have README files with additional information. 11. Where can I get documentation about Icon? The definitive work on Icon is the book The Icon Programming Language, Griswold and Griswold, third edition, Peer-to-Peer Communications, Inc, 1996, 386 pages, ISBN 1-57398-001-3. This book is a complete description and reference manual for Version 9 of Icon. A technical report describes changes since that version. There also is a book on the implementation of Icon: The Implementation of the Icon Programming Language, Griswold and Griswold, Princeton University Press, 1986, 336 pages, ISBN 0-691-08431-9. This book describes the implementation as of Version 6 of Icon. Although the implementation has changed considerably since then, the basic structure is the same. Technical reports describing recent implementation changes are included with copies of the book purchased from the Icon Project. These books are available from the Icon Project. Additional documentation is available via the web. Notable documents are: * IPD266: An Overview of Icon (HTML, text, PostScript, PDF) * IPD281: Graphics facilities (HTML, PostScript, PDF) * IPD278: Version 9.3 of Icon (HTML, text, PostScript, PDF) The Icon web page points to additional documentation, but there is no complete on-line documentation. The Icon Newsletter, which includes topical material about Icon and a list of material available from the Icon Project, is published three times a year and is available on the Web. There is a subscription fee for an on-going subscription by postal mail. The Icon Analyst, a technically-oriented newsletter that features articles about programming, is published six times a year. There is a subscription fee for the Analyst. A sample copy is available on the Web. All back issues of both newsletters are available for purchase. 12. How do I get started with Icon? If you're running under UNIX, check the web page at http://www.cs.arizona.edu/icon/v93u.htm to see if there is a "starter kit" for your platform. Starter kits include executables, documentation, and other material. Otherwise, go to ftp://ftp.cs.arizona.edu/icon/packages and get the appropriate package. Packages include documentation and other material; see the README file in that directory for more details. There is a UNIX package for platforms that lack starter kits. If the non-UNIX package you pick up does not contain executable files, check ftp://ftp.cs.arizona.edu/icon/binaries/. You also may want to get the overview of Icon noted in the previous answer. You'll find pointers to other documents of interest in the package you pick up. 13. What is the Icon Project? The Icon Project is a name used by the group that develops, implements, distributes, and supports the Icon programming language. The Icon Project is not commercial organization. It derives support from The University of Arizona, revenue from the sale of books and subscriptions, as well as user contributions. 14. Where can I find examples of Icon programs? There is a large program library for Icon. It is an excellent resource for both new and experienced programmers. The library contains numerous examples of how to do things with Icon. The library also provides many useful applications, as well as hundreds of procedures that supplement Icon's built-in repertoire. The library, like other Icon material, is available on-line. User contributions to the library are welcome. 15. What is Idol? Idol is an object-oriented extension to Icon that provides concepts such as classes and multiple inheritance. Idol is written in Idol and is distributed as part of the Icon program library. Idol runs on almost all of the platforms that support Icon. Additional Idol information is available from Clint Jeffery, jeffery@ringer.cs.utsa.edu. 16. How often is on-line material for Icon updated? New material is added when it's available. Established implementations usually are updated only when there's a new version. This typically is every year or two. The Icon program library is updated on a similar schedule. 17. How do I stay up to date with what's going on with Icon? The best way to find out about developments related to Icon is to read the Icon Newsletter. You can stay up to date on the source code, which is changed much more frequently than the on-line version is updated, by subscribing to the source update service, which provides a new version about twice a year. There also is a subscription service for updates to the Icon program library, which provides new material about twice a year. There is on-line information about subscribing to these services. 18. Is there a users' group for Icon? There is no official Icon users' group. The Icon Project maintains a moderated electronic mailing list, icon-group@cs.arizona.edu. Mail sent to this address is forwarded to subscribers. To subscribe (or unsubscribe), send a message to icon-group-request@cs.arizona.edu. There is a gateway between icon-group and comp.lang.icon, an unmoderated newsgroup for discussing issues related to Icon. The gateway, which exchanges messages between the two systems, is imperfect and not under the control of the Icon Project. The newsgroup generally provides faster response than the mailing list and is less intrusive, but it sometimes suffers from inappropriate postings. The Icon Project usually sends messages of interest to the Icon community to icon-group. 19. How do I get technical support? The Icon Project is not a commercial organization, and its capacity for providing technical support is limited. Please use the appropriate resource when you need assistance: Ordering Icon Material mail: Icon Project Department of Computer Science The University of Arizona P.O. Box 210077 Tucson, Arizona 85721-0077 U.S.A. fax: (520) 621-4246 voice: (520) 621-6613 e-mail: icon-orders@cs.arizona.edu Getting On-Line Information and Material web: http://www.cs.arizona.edu/icon/ ftp: ftp.cs.arizona.edu (cd /icon) e-mail: ftpmail@cs.arizona.edu Send a message consisting of the word help. Assistance with Installing Icon e-mail: icon-project@cs.arizona.edu Bug Reports e-mail: icon-project@cs.arizona.edu fax: (520) 621-4246 Assistance with Programming Problems e-mail: icon-group@cs.arizona.edu news: comp.lang.icon Uploading Files ftp: ftp.cs.arizona.edu (cd /incoming) After uploading, send e-mail to icon-project@cs.arizona.edu. 20. What do I need to run Icon? Icon will run on most modern platforms with standard configurations. Some programs may require more than the nominal amount of RAM. 21. Can I build my own implementation of Icon for a new platform? As mentioned above, Icon is written in C and the source code is available. The existing implementations are testaments to its portability. (A small amount of assembly-language code is required for a context switch, but this is only needed for an optional feature -- co-expressions -- that can be disabled without affecting other features of Icon.) New ports involve platform-specific configuration parameters and, in some cases, platform-specific code. The feasibility of a new port and the amount of work it may take depends on the platform -- its architecture, its C compiler, and its environment. Ports to new UNIX platforms generally are easy, although novel architectures may present problems. Ports to new operating systems generally are more difficult, especially if Icon's graphics facilities are implemented. The Icon Project provides what help it can with new ports. In return, it expects that code related to the port to be returned to the Icon Project for inclusion in future versions of the source code for Icon. This makes the new port available to others as well as to the porter when Icon is updated. Porting the Jcon system is another way to build an Icon system on a new platform. The Jcon translator is written in Icon and the runtime system is written in Java, which means that neither C nor assembly language is required for a port. Jcon's compiler-driver is a 400-line Korn shell script, which works well for Unix but may be an impediment to a non-Unix port. 22. What is ProIcon? ProIcon is an implementation of Version 8 of Icon for the Macintosh. It has a standard Macintosh interface, an integerated editor, and several extensions of standard Icon. ProIcon originally was a commerical product. After it was discontinued, it was placed in the public domain. The source code, however, is not available, because it contains proprietary and licensed components. ProIcon will not be upgraded. From icon-group-sender Mon Nov 2 08:46:21 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id IAA19372 for ; Mon, 2 Nov 1998 08:46:21 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA08548; Mon, 2 Nov 1998 08:45:43 -0700 Message-Id: <3.0.3.32.19981101202658.006c43dc@axionet.com> X-Sender: rlaing@axionet.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sun, 01 Nov 1998 20:26:58 -0800 To: icon-group@optima.CS.Arizona.EDU From: Richard Laing Subject: System Stack Overflow Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO "The Icon Programming Language" book at page 168 sez: "Unfortunately, system stack overflow may not be detected. If this happens, adjacent memory may be overwritten, resulting in program or system malfunction." So - how serious is this? Does it mean the system will crash, and therefore you will KNOW there is a problem? Or is it possible the program will continue to run but with bad data/results? Just started studying ICON, so don't have any real experience to report. Regards, Richard Laing Vancouver, CANADA rlaing@axionet.com rlaing@bigfoot.com http://www.geocities.com/Vienna/2392 ********************************************************* "Much may be made of a Scotchman if he be caught young." Samuel Johnson (1709-1784) ********************************************************* From icon-group-sender Mon Nov 2 13:03:54 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id NAA29504 for ; Mon, 2 Nov 1998 13:03:54 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA07975; Mon, 2 Nov 1998 13:03:17 -0700 Date: 2 Nov 98 12:09:10 +0500 From: Kostas Oikonomou Original-Date: Mon, 2 Nov 1998 12:09:10 -0500 (EST) To: icon-project@optima.CS.Arizona.EDU, icon-group@optima.CS.Arizona.EDU Subject: problem with procs/datetime.icn on Unix, Icon 9.3.1 X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-Id: <13885.58787.513131.187487@mara> Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Hello, It seems to me that SecToUnixDate(sec,hoursFromGmt) in procs/datetime.icn does not handle daylight savings time. That is, when I use a C program to convert a number of seconds since 1/1/1970 00:00:00 to a Unix data/time, I get a 1 hr. difference from what SecToUnixDate(sec,-5) reports. (-5 is my current hoursFromGmt). Is this well-known? What can be done about it? Thanks. Kostas Oikonomou From icon-group-sender Mon Nov 2 16:22:15 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id QAA08200 for ; Mon, 2 Nov 1998 16:22:13 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA09645; Mon, 2 Nov 1998 16:21:36 -0700 To: icon-group@optima.CS.Arizona.EDU Date: 02 Nov 1998 12:33:13 -1000 From: Robert Valliant Message-Id: Organization: University of Hawaii Sender: icon-group-request@optima.CS.Arizona.EDU Subject: How to read integers and others Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO I have an information retrieval program written in "c" that I would like to convert to a web application. The indexing portion of the application generates an inverted file of the format: word 32-bit integer word 32-bit integer . . . word 32-bit integer Can anyone tell me the best way to read these things, using icon? Or am I wasting my time in trying? thanks -- Robert Valliant Center for Russia in Asia University of Hawaii at Manoa valliant@hawaii.edu Fax: 808.956.2682 Tel: 808.956.7814 From icon-group-sender Tue Nov 3 09:09:48 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id JAA10063 for ; Tue, 3 Nov 1998 09:09:47 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA14547; Tue, 3 Nov 1998 09:09:10 -0700 Date: Mon, 2 Nov 1998 18:48:09 -0600 (CST) From: Ray Pereda X-Sender: rpereda@pandora To: Robert Valliant Cc: icon-group@optima.CS.Arizona.EDU Subject: Re: How to read integers and others In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO # Please RTFM, "String Scanning and Pattern Matching" chapter # in the Icon book, or scanning in one of the many online reference # documents. # Also, start by reading http://www.cs.arizona.edu/icon/intro.htm procedure main() while line := read() ? { tab(upto(&letters)) word := tab(many(&letters)) tab(upto(&digits)) num := integer(tab(many(&digits))) write("number: ", num, " word: ", word) } end -ray On 2 Nov 1998, Robert Valliant wrote: > I have an information retrieval program written in "c" that I would > like to convert to a web application. > > The indexing portion of the application generates an inverted file of > the format: > > word 32-bit integer > word 32-bit integer > . > . > . > word 32-bit integer > > Can anyone tell me the best way to read these things, using icon? Or > am I wasting my time in trying? > > thanks > > -- > Robert Valliant > Center for Russia in Asia > University of Hawaii at Manoa > valliant@hawaii.edu Fax: 808.956.2682 Tel: 808.956.7814 > > > From icon-group-sender Tue Nov 3 12:33:05 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id MAA19788 for ; Tue, 3 Nov 1998 12:33:04 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA14807; Tue, 3 Nov 1998 12:32:27 -0700 Date: Tue, 3 Nov 1998 09:30:12 -0700 From: swampler@noao.edu (Steve Wampler) Subject: Re: How to read integers and others To: icon-group@optima.CS.Arizona.EDU Message-Id: Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO - Forwarded message from rpereda@ringer.cs.utsa.edu on Mon, 2 Nov 1998 18:48:09 -0600 (CST) - > > # Please RTFM, "String Scanning and Pattern Matching" chapter > # in the Icon book, or scanning in one of the many online reference > # documents. > # Also, start by reading http://www.cs.arizona.edu/icon/intro.htm > > procedure main() > while line := read() ? { > tab(upto(&letters)) > word := tab(many(&letters)) > > tab(upto(&digits)) > num := integer(tab(many(&digits))) > > write("number: ", num, " word: ", word) > } > end > > -ray As I understand Robert's question, the above program will not work. He appears to want to scan in 32-bit integers, not ascii strings that 'look like' integers. That is, each word in his list is followed by the 4 bytes for the 32-bit integer (2's-complement, I assume). Robert, if I'm correct in how I'm interpreting your question, this isn't that easy to do directly in Icon. You'd have to read in the 4 bytes with reads() and the figure out to reconstruct the integer from that 4-byte string of ascii. (This isn't too hard if you are dealing with only non-negative values [the ord() function can help] but handling the 2-s complement for negative values strikes me as ugly.) Somebody has probably done this already. Incidently, you'd be better off if you used printf in your C retrieve program to output the 32-bit integer as it's ascii equivalent, in which case you could use a technique such as the one Ray suggests above. > On 2 Nov 1998, Robert Valliant wrote: > > > I have an information retrieval program written in "c" that I would > > like to convert to a web application. > > > > The indexing portion of the application generates an inverted file of > > the format: > > > > word 32-bit integer > > word 32-bit integer > > . > > . > > . > > word 32-bit integer > > > > Can anyone tell me the best way to read these things, using icon? Or > > am I wasting my time in trying? -- Steve Wampler - swampler@gemini.edu [Gemini 8m Telescopes Project (under AURA)] The gods that smiled at your birth are now laughing openly. (Fortune Cookie) From icon-group-sender Tue Nov 3 12:33:24 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id MAA19794 for ; Tue, 3 Nov 1998 12:33:24 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA12183; Tue, 3 Nov 1998 12:32:46 -0700 Date: Tue, 3 Nov 1998 09:50:40 -0700 From: Gregg Townsend Message-Id: <9811031650.AA03071@hawk.CS.Arizona.EDU> To: icon-group@optima.CS.Arizona.EDU, icon-project@optima.CS.Arizona.EDU, ko@mara.ho.att.com Subject: Re: problem with procs/datetime.icn on Unix, Icon 9.3.1 Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO From: Kostas Oikonomou It seems to me that SecToUnixDate(sec,hoursFromGmt) in procs/datetime.icn does not handle daylight savings time. That's right: it has no knowledge of time zones or daylight savings time, only a single correction factor. You need to incorporate the daylight savings time correction in the "hoursFromGmt" argument. --------------------------------------------------------------------------- Gregg Townsend Gould-Simpson Building gmt@cs.arizona.edu Staff Scientist 1040 E. 4th St. 32 13 45N 110 57 16W Dept. of Computer Science PO Box 210077 tel: +1 520 621 4325 The University of Arizona Tucson, AZ 85721-0077 fax: +1 520 621 4246 From icon-group-sender Tue Nov 3 12:32:54 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id MAA19784 for ; Tue, 3 Nov 1998 12:32:53 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA13943; Tue, 3 Nov 1998 12:32:15 -0700 Date: Tue, 3 Nov 1998 09:17:45 -0700 From: Gregg Townsend Message-Id: <9811031617.AA03583@hawk.CS.Arizona.EDU> To: icon-group@optima.CS.Arizona.EDU, rlaing@axionet.com Subject: Re: System Stack Overflow Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO From: Richard Laing "Unfortunately, system stack overflow may not be detected..." So - how serious is this? Does it mean the system will crash, and therefore you will KNOW there is a problem? Or is it possible the program will continue to run but with bad data/results? On Unix systems, the application can't cause a system crash, and it is very rare for stack overflow to be a problem. I've only seen it when co-expressions were used. In those few cases, it was clear that something was wrong, although the cause was not at all obvious. I can't really answer regarding Windows systems, but I would venture to guess that you most likely WILL know there is something wrong. --------------------------------------------------------------------------- Gregg Townsend Gould-Simpson Building gmt@cs.arizona.edu Staff Scientist 1040 E. 4th St. 32 13 45N 110 57 16W Dept. of Computer Science PO Box 210077 tel: +1 520 621 4325 The University of Arizona Tucson, AZ 85721-0077 fax: +1 520 621 4246 From icon-group-sender Tue Nov 3 12:33:17 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id MAA19791 for ; Tue, 3 Nov 1998 12:33:16 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA13162; Tue, 3 Nov 1998 12:32:39 -0700 Date: Tue, 3 Nov 1998 09:31:22 -0700 From: Gregg Townsend Message-Id: <9811031631.AA03653@hawk.CS.Arizona.EDU> To: icon-group@optima.CS.Arizona.EDU, valliant@hawaii.edu Subject: Re: How to read integers and others Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO From: Robert Valliant I have an information retrieval program written in "c" that I would like to convert to a web application. The indexing portion of the application generates an inverted file of the format: word 32-bit integer ... To read binary data in Icon: -- open the file in "untranslated" mode -- read multiples of 4 bytes using reads() -- convert characters to binary using ord(), and pack together -- or convert using pack/unpack from the Icon Program Library: http://www.cs.arizona.edu/icon/library/procs/binary.htm --------------------------------------------------------------------------- Gregg Townsend Gould-Simpson Building gmt@cs.arizona.edu Staff Scientist 1040 E. 4th St. 32 13 45N 110 57 16W Dept. of Computer Science PO Box 210077 tel: +1 520 621 4325 The University of Arizona Tucson, AZ 85721-0077 fax: +1 520 621 4246 From icon-group-sender Tue Nov 3 16:26:37 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id QAA00557 for ; Tue, 3 Nov 1998 16:26:37 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA15488; Tue, 3 Nov 1998 16:26:00 -0700 To: icon-group@optima.CS.Arizona.EDU Date: 3 Nov 1998 14:27:43 -0700 From: gmt@optima.CS.Arizona.EDU (Gregg Townsend) Message-Id: <71nsgf$275@hawk.CS.Arizona.EDU> Organization: University of Arizona CS Department, Tucson AZ Sender: icon-group-request@optima.CS.Arizona.EDU References: <9811031650.AA03071@hawk.CS.Arizona.EDU>, <71nr1n$pre@dfw-ixnews10.ix.netcom.com> Subject: Re: problem with procs/datetime.icn on Unix, Icon 9.3.1 Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO > Is this, perhaps, related to the fact that Icon's home, the State of Arizona, > does not participate in daylight savings time? Good guess, but that procedure was actually contributed by a Californian! From icon-group-sender Tue Nov 3 16:26:46 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id QAA00560 for ; Tue, 3 Nov 1998 16:26:46 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA15498; Tue, 3 Nov 1998 16:26:08 -0700 To: icon-group@optima.CS.Arizona.EDU Date: Tue, 3 Nov 1998 13:07:35 -0800 From: "Michael T. Jones" Message-Id: <71nr1n$pre@dfw-ixnews10.ix.netcom.com> Organization: Intrinsic Software Sender: icon-group-request@optima.CS.Arizona.EDU References: <9811031650.AA03071@hawk.CS.Arizona.EDU> Subject: Re: problem with procs/datetime.icn on Unix, Icon 9.3.1 Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Gregg Townsend wrote in message <9811031650.AA03071@hawk.CS.Arizona.EDU>... : From: Kostas Oikonomou : : It seems to me that SecToUnixDate(sec,hoursFromGmt) in procs/datetime.icn : does not handle daylight savings time. : :That's right: it has no knowledge of time zones or daylight savings time, :only a single correction factor. You need to incorporate the daylight :savings time correction in the "hoursFromGmt" argument. Is this, perhaps, related to the fact that Icon's home, the State of Arizona, does not participate in daylight savings time? From icon-group-sender Wed Nov 4 16:53:44 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id QAA02068 for ; Wed, 4 Nov 1998 16:53:43 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA00915; Wed, 4 Nov 1998 16:53:43 -0700 To: icon-group@optima.CS.Arizona.EDU Date: 04 Nov 1998 08:28:52 -1000 From: Robert Valliant Message-Id: Organization: University of Hawaii Sender: icon-group-request@optima.CS.Arizona.EDU References: Subject: Re: How to read integers and others Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO My thanks to all who responded. I do have to apologize if my query was somewhat unclear. I thought there would have to be a standard solution somewhere, otherwise how could icon read files created by other programs? I will first look at the icon library. Ray Pereda offered to help. I will ask him if I can't figure it out. It is nice that us amateurs can depend on such things as the icon library and on all the pro's out there who are kind enough to devote their time to help us. I use icon because it helps me get the work done, and it relieves me of all the nitty gritty that those poor c programmers have to put up with. Robert Valliant Center for Russia in Asia University of Hawaii at Manoa valliant@hawaii.edu Fax: 808.956.2682 Tel: 808.956.7814 From icon-group-sender Thu Nov 12 12:50:03 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id MAA24012 for ; Thu, 12 Nov 1998 12:50:03 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA06488; Thu, 12 Nov 1998 12:50:02 -0700 To: icon-group@optima.CS.Arizona.EDU Date: Thu, 12 Nov 1998 21:11:38 +0800 From: Belldandy Message-Id: <364ADE8A.BF5CB0F1@tpts5.seed.net.tw> Organization: SEEDNet News Service Sender: icon-group-request@optima.CS.Arizona.EDU Subject: About Wi... Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO The Windows distrubution's helpfiles told something about a program called Wi, but I couldn't find it anywhere. Does anyone know where is it? Thanks! From icon-group-sender Fri Nov 13 12:39:19 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id MAA27101 for ; Fri, 13 Nov 1998 12:39:19 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA07299; Fri, 13 Nov 1998 12:39:18 -0700 Date: Fri, 13 Nov 1998 12:09:03 -0500 (EST) From: Mark Laster To: icon-group@optima.CS.Arizona.EDU Subject: Coding multi-part patterns, as in SNOBOL Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Subject: Coding multi-part patterns, as in SNOBOL Friday, 11/13/98 Hello, After years of programming in SNOBOL, I've been learning ICON, but some operations in ICON require me (because I don't know a neater way) to write far more lines of code than would be necessary in SNOBOL. One of my programs in ICON processes e-mail messages. It does more than the snippet shown here, but for purposes of discussion, it removes the "e-mail quotation" marks from lines of text. As you know, those marks in aggregate may be either: (1) one or more angle brackets, starting at the left margin, or (2) one or more spaces, starting at the left margin, FOLLOWED IMMEDIATELY BY one or more angle brackets. To remove these "e-mail quote" marks, I needed about 20 lines, as shown below. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - procedure main ( ) ... # have gotten a line of text, called "rec" here, by now repeat { if /rec then { rec := " " break } else if locnb := many('>', rec) then rec := rec[locnb:0] if dbg1 := (many(' ', rec)) then { if dbg2 := (many('>', rec[dbg1])) then rec := rec[dbg1+dbg2-1:0] else # found starting blanks but no ">" immediately after break } # end of "if dbg1 := (many(' ' ..." else # rec line does not start with blank or ">" break } # repeat for each workline # write the record out ... end - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To perform the same operation in SNOBOL requires two lines (if that many): ... qupat = pos(0) (span(" ") | null) span(">") rem . rec ... strip rec qupat :s(strip) ... end - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - I've read through the file PATTERNS.ICN, written in 1988, and I know how to $include it, but I don't know how to use it. I'd be glad to lose some run-time efficiency in order to gain some coding-time efficiency. Assuming that there is a way to code the quote-stripping operation in ICON more efficiently than I have, optionally using the PATTERNS.ICN file or superseding files, could you show me how to do it in ICON, so I can see how to combine multiple conditions in a match: (1) starting at the left margin (2) optionally encountering one or more blanks (3) encountering one or more ">" directly afterward. That would help me learn how to code a variety of complex conditions. Thank you very much. Sincerely yours, Mark Laster (301) 805-4462 mlaster@smart.net 15775 Easthaven Court Bowie, MD 20716-2620 From icon-group-sender Fri Nov 13 16:45:35 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id QAA04592 for ; Fri, 13 Nov 1998 16:45:31 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA07516; Fri, 13 Nov 1998 16:45:30 -0700 Message-Id: <4FD6422BE942D111908D00805F3158DF0757B73A@RED-MSG-52> From: Todd Proebsting To: "'Mark Laster'" , icon-group@optima.CS.Arizona.EDU Subject: RE: Coding multi-part patterns, as in SNOBOL Date: Fri, 13 Nov 1998 12:59:48 -0800 X-Mailer: Internet Mail Service (5.5.2232.9) Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO I believe the following "strip()" routine will do what you want. (It is possible to write it more concisely, but at the expense of clarity.) The "main()" routine simply provides a driver routine that reads lines, strips them and prints the results. Todd Proebsting procedure main() while write(strip(read())) end procedure strip(s) s ? { # scan string tab(many(' ')) # tab past spaces if tab(many('>')) then { # tab past >'s return tab(0) # return remainder } else { return s # no >'s, so return s } } end -----Original Message----- From: Mark Laster [mailto:mlaster@smart.net] Sent: Friday, November 13, 1998 9:09 AM To: icon-group@optima.CS.Arizona.EDU Subject: Coding multi-part patterns, as in SNOBOL Subject: Coding multi-part patterns, as in SNOBOL Friday, 11/13/98 Hello, After years of programming in SNOBOL, I've been learning ICON, but some operations in ICON require me (because I don't know a neater way) to write far more lines of code than would be necessary in SNOBOL. One of my programs in ICON processes e-mail messages. It does more than the snippet shown here, but for purposes of discussion, it removes the "e-mail quotation" marks from lines of text. As you know, those marks in aggregate may be either: (1) one or more angle brackets, starting at the left margin, or (2) one or more spaces, starting at the left margin, FOLLOWED IMMEDIATELY BY one or more angle brackets. To remove these "e-mail quote" marks, I needed about 20 lines, as shown below. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - procedure main ( ) ... # have gotten a line of text, called "rec" here, by now repeat { if /rec then { rec := " " break } else if locnb := many('>', rec) then rec := rec[locnb:0] if dbg1 := (many(' ', rec)) then { if dbg2 := (many('>', rec[dbg1])) then rec := rec[dbg1+dbg2-1:0] else # found starting blanks but no ">" immediately after break } # end of "if dbg1 := (many(' ' ..." else # rec line does not start with blank or ">" break } # repeat for each workline # write the record out ... end - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To perform the same operation in SNOBOL requires two lines (if that many): ... qupat = pos(0) (span(" ") | null) span(">") rem . rec ... strip rec qupat :s(strip) ... end - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - I've read through the file PATTERNS.ICN, written in 1988, and I know how to $include it, but I don't know how to use it. I'd be glad to lose some run-time efficiency in order to gain some coding-time efficiency. Assuming that there is a way to code the quote-stripping operation in ICON more efficiently than I have, optionally using the PATTERNS.ICN file or superseding files, could you show me how to do it in ICON, so I can see how to combine multiple conditions in a match: (1) starting at the left margin (2) optionally encountering one or more blanks (3) encountering one or more ">" directly afterward. That would help me learn how to code a variety of complex conditions. Thank you very much. Sincerely yours, Mark Laster (301) 805-4462 mlaster@smart.net 15775 Easthaven Court Bowie, MD 20716-2620 From icon-group-sender Fri Nov 13 16:45:14 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id QAA04587 for ; Fri, 13 Nov 1998 16:45:13 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA07478; Fri, 13 Nov 1998 16:45:13 -0700 Date: Fri, 13 Nov 1998 13:26:24 -0700 From: swampler@noao.edu (Steve Wampler) Subject: Re: Coding multi-part patterns, as in SNOBOL To: icon-group@optima.CS.Arizona.EDU Message-Id: In-Reply-To: Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Mark Laster wrote: > One of my programs in ICON processes e-mail messages. It does > more than the snippet shown here, but for purposes of > discussion, it removes the "e-mail quotation" marks from lines of > text. As you know, those marks in aggregate may be either: > > (1) one or more angle brackets, starting at the left margin, or > > (2) one or more spaces, starting at the left margin, FOLLOWED > IMMEDIATELY BY one or more angle brackets. > > To remove these "e-mail quote" marks, I needed about 20 lines, > as shown below. > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > To perform the same operation in SNOBOL requires two lines (if > that many): > > ... > qupat = pos(0) (span(" ") | null) span(">") rem . rec > ... > strip rec qupat :s(strip) > ... > end > I haven't had a chance to test this (busy, busy), but something like the following should work in Icon (note how it's capitalized): procedure strip(s) while s ?:= (tab(many('> ')), tab(0)) return s end This is even shorter than the SNOBOL you gave, but you can do something similar in SNOBOL, also. -- Steve Wampler - swampler@gemini.edu [Gemini 8m Telescopes Project (under AURA)] The gods that smiled at your birth are now laughing openly. (Fortune Cookie) From icon-group-sender Mon Nov 16 12:46:59 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id MAA22393 for ; Mon, 16 Nov 1998 12:46:58 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA08430; Mon, 16 Nov 1998 12:46:58 -0700 Message-Id: <4FD6422BE942D111908D00805F3158DF0757B742@RED-MSG-52> From: Todd Proebsting To: "'nr@labrador.cs.virginia.edu'" , icon-group@optima.CS.Arizona.EDU Subject: RE: Coding multi-part patterns, as in SNOBOL Date: Mon, 16 Nov 1998 10:03:46 -0800 X-Mailer: Internet Mail Service (5.5.2232.9) Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO >From the request, I inferred---perhaps wrongly---that initial blanks were to be removed *only* if followed by at least one angle bracket. The solution below always removes initial blanks, regardless of what follows. Todd Proebsting -----Original Message----- From: nr@labrador.cs.virginia.edu [mailto:nr@labrador.cs.virginia.edu] Sent: Friday, November 13, 1998 2:44 PM To: icon-group@optima.CS.Arizona.EDU Subject: Re: Coding multi-part patterns, as in SNOBOL In article , Mark Laster wrote: >One of my programs in ICON processes e-mail messages. It does >more than the snippet shown here, but for purposes of >discussion, it removes the "e-mail quotation" marks from lines of >text. As you know, those marks in aggregate may be either: > > (1) one or more angle brackets, starting at the left margin, or > > (2) one or more spaces, starting at the left margin, FOLLOWED > IMMEDIATELY BY one or more angle brackets. > >To remove these "e-mail quote" marks, I needed about 20 lines, >as shown below. procedure strip_email_quote(s) return s ? { tab(many(' ')); tab(many('>')); tab(0) } end From icon-group-sender Mon Nov 23 09:46:34 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id JAA07648 for ; Mon, 23 Nov 1998 09:46:34 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA11023; Mon, 23 Nov 1998 09:46:33 -0700 To: icon-group@optima.CS.Arizona.EDU Date: Sun, 22 Nov 1998 01:31:54 GMT From: fschiff@mindspring.com (Fred Schiff) Message-Id: <365765d1.35696090@news.mindspring.com> Organization: MindSpring Enterprises Sender: icon-group-request@optima.CS.Arizona.EDU Reply-To: fschiff@mindspring.com Subject: Difference 2nd edition vs 3rd edition? Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Whats the difference between 2nd and 3rd edition of the "Icon Programming" book. I have the older book and want to know if it pays to pick up the new one. I have just sent for the Graphics book and was wondering what's covered language wise that I wont't have information on. From icon-group-sender Mon Nov 23 09:46:46 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id JAA07652 for ; Mon, 23 Nov 1998 09:46:46 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA11028; Mon, 23 Nov 1998 09:46:45 -0700 To: icon-group@optima.CS.Arizona.EDU Date: Sun, 22 Nov 1998 17:02:02 -0600 From: "Kal Torak" Message-Id: Sender: icon-group-request@optima.CS.Arizona.EDU References: <364ADE8A.BF5CB0F1@tpts5.seed.net.tw> Subject: Re: About Wi... Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Wi can be found in the Window Icon distribution at: ftp://ringer.cs.utsa.edu/pub/icon/nt/binaries/winicon.zip Belldandy wrote in message <364ADE8A.BF5CB0F1@tpts5.seed.net.tw>... >The Windows distrubution's helpfiles told something about > >a program called Wi, but I couldn't find it anywhere. Does > >anyone know where is it? Thanks! From icon-group-sender Mon Nov 23 09:47:00 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id JAA07660 for ; Mon, 23 Nov 1998 09:47:00 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA11039; Mon, 23 Nov 1998 09:46:59 -0700 To: icon-group@optima.CS.Arizona.EDU Date: Sun, 22 Nov 1998 17:12:10 -0600 From: "Kal Torak" Message-Id: Sender: icon-group-request@optima.CS.Arizona.EDU References: <365765d1.35696090@news.mindspring.com> Subject: Re: Difference 2nd edition vs 3rd edition? Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO The cover of the third edition book is blue while I believe that the second edition cover is red. What more do you want? No seriously, from the third edition: "... The second edition [of this book] described Version 8. The third edition describes Version 9.3. It not only includes descriptions of features that have been added since version 8, but it also is completely revised. It contains many improvements based on continuing experience in teaching and using Icon." Hope that this helps. I don't exactly have a list of the new features in version 9.3, but it's possible that they may be in a readme file if you download it. Kal Torak --- If we aren't supposed to eat animals, why are they made out of meat? Fred Schiff wrote in message <365765d1.35696090@news.mindspring.com>... >Whats the difference between 2nd and 3rd edition of the "Icon >Programming" book. I have the older book and want to know if it pays >to pick up the new one. I have just sent for the Graphics book and >was wondering what's covered language wise that I wont't have >information on. From icon-group-sender Wed Nov 25 13:54:17 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id NAA18015 for ; Wed, 25 Nov 1998 13:54:16 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA01317; Wed, 25 Nov 1998 13:54:16 -0700 X-Lotus-Fromdomain: JOHNSON_CONTROLS From: "Tenaglia, Chris D" To: icon-group@optima.CS.Arizona.EDU Message-Id: <862566C7.00544717.00@Corpnotes.JCI.Com> Date: Wed, 25 Nov 1998 09:05:36 -0600 Subject: Icon for Alpha/VMS Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO I have Icon running very well on some VAX/VMS systems. Now there is a new architecture called Alpha or AXP. Compaq/Dec has a tool called VEST which interprets the VAX executable. This works for many programs. But when I tried it with ICONT.EXE or ICONX.EXE there were errors and version mismatches with libraries. Next I just tried to rebuild it since we have a development system. But on Alpha the compiler is DEC-C instead of VAX-c and there differences. Such as DEC-c does not initialze variables automatically as VAX-c did. There were very many compile errors. My knowledge of C falls way short of debugging it. Is anyone else looking at migrating to the Alpha/VMS environment? Or many used a different set of flags for the VEST translation that worked? Thanks in advance, Chris Tenaglia, technical analyst Johnson Controls, Inc From icon-group-sender Mon Nov 30 08:52:47 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id IAA15782 for ; Mon, 30 Nov 1998 08:52:47 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA02320; Mon, 30 Nov 1998 08:52:47 -0700 Message-Id: <365F858B.3DE6@gte.net> Date: Fri, 27 Nov 1998 23:09:31 -0600 From: MJE Reply-To: evans@gte.net Organization: None X-Mailer: Mozilla 3.01 (Win95; I) Mime-Version: 1.0 To: icon-group@optima.CS.Arizona.EDU Cc: evans@gte.net Subject: Commercial Use References: <862566C7.00544717.00@Corpnotes.JCI.Com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Errors-To: icon-group-errors@optima.CS.Arizona.EDU Content-Transfer-Encoding: 7bit Status: RO This should be on the Icon FAQ. Here goes: "Is it permitted to incorporate any or all features of the Icon language, including compiled Icon Project source code, in a commercial package?" My interest stems from the fact that I use about half a dozen programs which stink when it comes to string processing. Things get very painful when we have to interpret files or ascii data streams. I am talking about major league packages like Mathematica and MATLAB. So, my thought is to recommend to some vendors that they look into using pieces of Icon in their product. Who knows, it might generate some consulting fees for the Icon Project. (= funds for improvements.) In the back of my mind I recall hearing that Icon could be used commercially in a royalty-free manner. There is a comment on the download page to the effect that "all material here is in the public domain." So please answer the query and would someone in the know get it onto the Icon FAQ. Mark Evans From icon-group-sender Mon Nov 30 08:52:32 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id IAA15735 for ; Mon, 30 Nov 1998 08:52:28 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA02285; Mon, 30 Nov 1998 08:52:28 -0700 To: icon-group@optima.CS.Arizona.EDU Date: 25 Nov 1998 16:00:10 -0500 From: "Tenaglia, Chris D" Message-Id: <862566C7.00544717.00@Corpnotes.JCI.Com> Organization: IDA, Alexandria, Virginia Sender: icon-group-request@optima.CS.Arizona.EDU Subject: Icon for Alpha/VMS Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO I have Icon running very well on some VAX/VMS systems. Now there is a new architecture called Alpha or AXP. Compaq/Dec has a tool called VEST which interprets the VAX executable. This works for many programs. But when I tried it with ICONT.EXE or ICONX.EXE there were errors and version mismatches with libraries. Next I just tried to rebuild it since we have a development system. But on Alpha the compiler is DEC-C instead of VAX-c and there differences. Such as DEC-c does not initialze variables automatically as VAX-c did. There were very many compile errors. My knowledge of C falls way short of debugging it. Is anyone else looking at migrating to the Alpha/VMS environment? Or many used a different set of flags for the VEST translation that worked? Thanks in advance, Chris Tenaglia, technical analyst Johnson Controls, Inc From icon-group-sender Mon Nov 30 13:31:58 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id NAA01264 for ; Mon, 30 Nov 1998 13:31:57 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA02506; Mon, 30 Nov 1998 13:31:56 -0700 Sender: u6gaf@csc.liv.ac.uk Message-Id: <3662C278.187B@csc.liv.ac.uk> Date: Mon, 30 Nov 1998 16:06:16 +0000 From: "G.A. Finlay" X-Mailer: Mozilla 3.04 (X11; I; HP-UX B.10.20 9000/710) Mime-Version: 1.0 To: icon-group@optima.CS.Arizona.EDU Subject: icon text browser Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Errors-To: icon-group-errors@optima.CS.Arizona.EDU Content-Transfer-Encoding: 7bit Status: RO I am currently a third year Computer Science student at the University of Liverpool. As part of my Honours project I have to write a program which involves the use of a simple text browser. I wondered whether there were any existing programs for creating a simple text file browser. I would be grateful if you could get back to me with any information on this. Grant Finlay e-mail: u6gaf@csc.lic.ac.uk From icon-group-sender Mon Nov 30 13:31:35 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id NAA01239 for ; Mon, 30 Nov 1998 13:31:34 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA02489; Mon, 30 Nov 1998 13:31:34 -0700 Date: Mon, 30 Nov 1998 09:12:27 -0700 From: Ralph Griswold Message-Id: <9811301612.AA06252@jupiter.CS.Arizona.EDU> To: evans@gte.net Subject: Re: Commercial Use Cc: icon-group Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO There are no restrictions on the use of Icon -- commercial or otherwise. I'll make a note to add that to the Icon FAQ. Ralph From icon-group-sender Mon Nov 30 16:36:27 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id QAA12590 for ; Mon, 30 Nov 1998 16:36:25 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA02561; Mon, 30 Nov 1998 16:36:25 -0700 Date: Mon, 30 Nov 1998 15:52:07 -0600 (CST) From: David S Cargo Message-Id: <199811302152.PAA02274@mirage.skypoint.com> To: icon-group@optima.CS.Arizona.EDU, u6gaf@csc.liv.ac.uk Subject: Re: icon text browser Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO The Icon Program Library contains some, including fish-eye view. Check the IPL index at http://www.cs.arizona.edu/icon/library/ipl.htm (fev.icn == fish-eye view). From icon-group-sender Wed Dec 2 10:11:43 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id KAA21445 for ; Wed, 2 Dec 1998 10:11:43 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA03092; Wed, 2 Dec 1998 10:11:42 -0700 To: icon-group@optima.CS.Arizona.EDU Date: Wed, 2 Dec 1998 08:27:45 -0800 From: "Paul A. Sue" Message-Id: <743pci$5081@gargoyle.bctel.com> Organization: British Columbia Telephone Company Sender: icon-group-request@optima.CS.Arizona.EDU Subject: Icon Book on Net Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Hi, Quite a few months, someone posted the URL for an Icon book that they were writing. It was an Acrobat file. I seem to have lost it. Can someone pls. e-mail me the URL? Thanks, Paul psue99@netscape.net or paul_sue@ismbc.com From icon-group-sender Wed Dec 2 13:49:07 1998 Return-Path: Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id NAA28594 for ; Wed, 2 Dec 1998 13:49:06 -0700 (MST) Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA03205; Wed, 2 Dec 1998 13:49:05 -0700 X-Lotus-Fromdomain: ISM-BC From: "Paul A. Sue" To: icon-group@optima.CS.Arizona.EDU Message-Id: <882566CE.0061B63A.00@ismbcln05.ismbc.com> Date: Wed, 2 Dec 1998 09:45:10 -0800 Subject: list archive?? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Hi, Is this mailing list archived anywhere? [I'm trying to locate a posting several montha ago re: a new book on learning Icon that was available as an Acrobat doc. on the net. I've forgotten the URL.] Thanks, Paul ======================================= Paul A. Sue, Consultant ISM-BC AD/M Voice-mail: (604) 419-7309 Pager: (604) 977-8729 E-mail: psue99@netscape.net [or paul@wsi.ca] From icon-group-sender Wed Dec 2 18:27:32 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id SAA09605 for icon-group-addresses; Wed, 2 Dec 1998 18:27:20 -0700 (MST) Message-Id: <199812030127.SAA09605@baskerville.CS.Arizona.EDU> Date: Wed, 2 Dec 1998 15:14:21 -0700 From: Ralph Griswold To: icon-group Subject: Icon Newsletter 57 Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Icon Newsletter 57 now is available on-line: http://www.cs.arizona.edu/icon/inl/inl57/inl57.htm From icon-group-sender Thu Dec 3 16:32:01 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA09536 for icon-group-addresses; Thu, 3 Dec 1998 16:28:42 -0700 (MST) Message-Id: <199812032328.QAA09536@baskerville.CS.Arizona.EDU> Date: Thu, 03 Dec 1998 15:17:16 -0600 From: "Thomas W. Christopher" X-Accept-Language: en To: "Paul A. Sue" CC: icon-group@optima.CS.Arizona.EDU Subject: Re: Icon Book on Net Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO It's moved. The new URL is: http://www.toolsofcomputing.com/freesoftware.htm "Paul A. Sue" wrote: > Hi, > > Quite a few months, someone posted the URL for > an Icon book that they were writing. It was an > Acrobat file. I seem to have lost it. > > Can someone pls. e-mail me the URL? > > Thanks, > > Paul > psue99@netscape.net or paul_sue@ismbc.com -- Thomas W. Christopher -- tc@charlie.cns.iit.edu , tc@toolsofcomputing.com Principal, Tools of Computing LLC. -- http://www.toolsofcomputing.com Associate Prof., Illinois Inst. of Tech. -- http://www.iit.edu/~tc From icon-group-sender Thu Dec 3 16:36:09 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA09709 for icon-group-addresses; Thu, 3 Dec 1998 16:36:03 -0700 (MST) Message-Id: <199812032336.QAA09709@baskerville.CS.Arizona.EDU> Date: Thu, 3 Dec 1998 15:06:35 -0700 From: Ralph Griswold To: icon-group Subject: Update Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Whoops. I notice in the newsletter you have a listing for my on-line Icon book, but we've changed the domain name for our company, so the URL is out of date. Here's the new URL: http://www.toolsofcomputing.com/freesoftware.htm Sorry. -- Thomas W. Christopher -- tc@charlie.cns.iit.edu , tc@toolsofcomputing.com Principal, Tools of Computing LLC. -- http://www.toolsofcomputing.com Associate Prof., Illinois Inst. of Tech. -- http://www.iit.edu/~tc From icon-group-sender Thu Dec 3 16:36:28 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA09748 for icon-group-addresses; Thu, 3 Dec 1998 16:36:23 -0700 (MST) Message-Id: <199812032336.QAA09748@baskerville.CS.Arizona.EDU> X-Lotus-FromDomain: ISM-BC From: "Paul A. Sue" To: icon-group@optima.CS.Arizona.EDU Date: Thu, 3 Dec 1998 15:05:19 -0800 Subject: Icon to C interface Content-Disposition: inline Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Hi, >From what little I've learned of Icon, I think it's a great language. Since C is the de facto language where I work (though I push Perl, Tcl/Tk, Python, (and now Icon), etc. where appropriate), I would like to know if there is a way to interface Icon with C (i.e. call C functions from Icon, or call an Icon procedure from C) ?? Thanks, Paul ======================================= Paul A. Sue, Consultant ISM-BC AD/M Voice-mail: (604) 419-7309 Pager: (604) 977-8729 E-mail: psue99@netscape.net [or paul@wsi.ca] From icon-group-sender Fri Dec 4 12:32:27 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA29771 for icon-group-addresses; Fri, 4 Dec 1998 12:31:49 -0700 (MST) Message-Id: <199812041931.MAA29771@baskerville.CS.Arizona.EDU> To: icon-group@optima.CS.Arizona.EDU Date: Fri, 4 Dec 1998 14:54:14 +0100 From: a friend Subject: Re: Icon Book on Net Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO On Wed, 2 Dec 1998, Paul A. Sue wrote: > Hi, > > Quite a few months, someone posted the URL for > an Icon book that they were writing. It was an > Acrobat file. I seem to have lost it. > > Can someone pls. e-mail me the URL? > > Thanks, > > Paul > psue99@netscape.net or paul_sue@ismbc.com > > Hi look at at the homepage of icon there is a link bye Martin From icon-group-sender Mon Dec 7 08:34:19 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA08307 for icon-group-addresses; Mon, 7 Dec 1998 08:31:42 -0700 (MST) Message-Id: <199812071531.IAA08307@baskerville.CS.Arizona.EDU> To: icon-group@optima.CS.Arizona.EDU Date: 4 Dec 98 18:54:10 GMT From: hgs@dmu.ac.uk (Hugh Sasse) Subject: Building on Solaris 2.5.1 sparc gcc Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Following the instructions in the HTML file on the WWW site, after downloading the package dated Feb 1998, on my Sun Solaris 2.5.1 Sparc, GCC 2.7.2 system make X-Configure name=sun_gcc went OK but: atlanta hgs 186 %> make Icon make Icon-icont cd src/common; make gcc -O -DNOTHING -c doincl.c In file included from ../h/../h/sys.h:294, from ../h/rt.h:15, from doincl.c:14: ../h/../h/../xpm/xpm.h:20: X11/Xlib.h: No such file or directory ../h/../h/../xpm/xpm.h:21: X11/Intrinsic.h: No such file or directory ../h/../h/../xpm/xpm.h:29: X11/Xutil.h: No such file or directory In file included from ../h/rt.h:15, from doincl.c:14: ../h/../h/sys.h:299: X11/Xutil.h: No such file or directory ../h/../h/sys.h:300: X11/Xos.h: No such file or directory ../h/../h/sys.h:301: X11/Xatom.h: No such file or directory *** Error code 1 make: Fatal error: Command failed for target `doincl.o' Current working directory /home/hgs/icon/src/common *** Error code 1 make: Fatal error: Command failed for target `Common' Current working directory /home/hgs/icon *** Error code 1 make: Fatal error: Command failed for target `Icon' atlanta hgs 187 %> So it doesn't seem to have picked up the defines or the include paths for X. Has anyone done this? I have seen that there are a lot of calls to different makefiles, but the paths are getting me quite confused as to which one to try to fix. Replies by mail would be helpful as the newserver seems a bit wobbly recently. Thank you, Hugh hgs@dmu.ac.uk From icon-group-sender Mon Dec 7 08:36:33 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA08642 for icon-group-addresses; Mon, 7 Dec 1998 08:36:23 -0700 (MST) Message-Id: <199812071536.IAA08642@baskerville.CS.Arizona.EDU> Date: Sat, 05 Dec 1998 13:56:29 -0600 From: MJE To: icon-group@optima.CS.Arizona.EDU CC: Ralph Griswold , jeffery@cs.utsa.edu, evans@gte.net Subject: Past Keyword / Coexpr Help Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO This is a multi-part message in MIME format. --------------3C6B6947244B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit It seems that Icon is missing a somewhat important string scanning mechanism. Second, I need advice about coexpressions. The questions are related because the scanning mechanism I have in mind would assist the use of parallel coexpressions. The scanning mechanism I want would perhaps be called "past", as in numberchars := (&digits ++ 'e' ++ 'E' ++ '+' ++ '-' ++ '.') string ? { tab(past("substring")) result := real(tab(many(numberchars))) } There is a keyword "match" but that call only works if the substring exists at the start of "string". What I want is a "past" keyword which simultaneously finds and skips past a substring. It would be the converse of "upto" I suppose. Now to the question about coexpressions. Attached below is an ASCII file which came directly out of a Tektronix scope. It gives parameters for trace data. I am interested to pull out, as real numbers, the parameters for the x and y scales on the scope. I want to assign these numbers to variables in Icon. I can define a coexpression for the substrings, params := create ("XMULT:" | "XZERO:" | "YMULT:" | "YZERO:") and following the Icon book, we can write every (xmult | xzero | ymult | yzero) := <...do something here...> where the right hand side would involve @params. The problem is, I don't know what the r.h.s should be. Help! I could simply put four separate scanning constructs in my code, one for each variable of interest. I would rather learn how to exploit Icon's coexpressions to make the code compact. Best regards, Mark Evans --------------3C6B6947244B Content-Type: text/plain; charset=us-ascii; name="Sarpre.txt" Content-Disposition: inline; filename="Sarpre.txt" Content-Transfer-Encoding: 7bit WFMPRE WFID:STO1,LABEL:"",BIT/NR:16,BN.FMT:RI,BYT/NR:2,BYT.OR:LSB,CRVCHK:NONE,ENCDG:ASCII,NR.PT:512,PT.FMT:Y,RHOFACTOR:1.0E+0,RHOPOS:0.0E+0,XINCR:4.0E-12,XMULT:1.5625E-4,XUNIT:SECONDS,XZERO:4.913E-8,YMULT:1.5625E-6,YUNIT:VOLTS,YZERO:0.0E+0,TIME:"14:06:30",DATE:" 2-DEC-98";WFMPRE WFID:STO2,LABEL:"",BIT/NR:16,BN.FMT:RI,BYT/NR:2,BYT.OR:LSB,CRVCHK:NONE,ENCDG:ASCII,NR.PT:512,PT.FMT:Y,RHOFACTOR:1.0E+0,RHOPOS:0.0E+0,XINCR:4.0E-12,XMULT:1.5625E-4,XUNIT:SECONDS,XZERO:4.913E-8,YMULT:1.5625E-6,YUNIT:VOLTS,YZERO:0.0E+0,TIME:"14:06:51",DATE:" 2-DEC-98";WFMPRE WFID:STO3,LABEL:"",BIT/NR:16,BN.FMT:RI,BYT/NR:2,BYT.OR:LSB,CRVCHK:NONE,ENCDG:ASCII,NR.PT:512,PT.FMT:Y,RHOFACTOR:1.0E+0,RHOPOS:0.0E+0,XINCR:4.0E-12,XMULT:1.5625E-4,XUNIT:SECONDS,XZERO:4.913E-8,YMULT:1.5625E-6,YUNIT:VOLTS,YZERO:0.0E+0,TIME:"14:07:09",DATE:" 2-DEC-98";WFMPRE WFID:STO4,LABEL:"",BIT/NR:16,BN.FMT:RI,BYT/NR:2,BYT.OR:LSB,CRVCHK:NONE,ENCDG:ASCII,NR.PT:512,PT.FMT:Y,RHOFACTOR:1.0E+0,RHOPOS:0.0E+0,XINCR:4.0E-12,XMULT:1.5625E-4,! XU! NIT:SECONDS,XZERO:4.913E-8,YMULT:1.5625E-6,YUNIT:VOLTS,YZERO:0.0E+0,TIME:"14:07:24",DATE:" 2-DEC-98";WFMPRE WFID:STO5,LABEL:"",BIT/NR:16,BN.FMT:RI,BYT/NR:2,BYT.OR:LSB,CRVCHK:NONE,ENCDG:ASCII,NR.PT:512,PT.FMT:Y,RHOFACTOR:1.0E+0,RHOPOS:0.0E+0,XINCR:4.0E-12,XMULT:1.5625E-4,XUNIT:SECONDS,XZERO:4.913E-8,YMULT:1.5625E-6,YUNIT:VOLTS,YZERO:0.0E+0,TIME:"14:07:38",DATE:" 2-DEC-98";WFMPRE WFID:STO6,LABEL:"",BIT/NR:16,BN.FMT:RI,BYT/NR:2,BYT.OR:LSB,CRVCHK:NONE,ENCDG:ASCII,NR.PT:512,PT.FMT:Y,RHOFACTOR:1.0E+0,RHOPOS:0.0E+0,XINCR:4.0E-12,XMULT:1.5625E-4,XUNIT:SECONDS,XZERO:4.913E-8,YMULT:1.5625E-6,YUNIT:VOLTS,YZERO:0.0E+0,TIME:"14:07:50",DATE:" 2-DEC-98";WFMPRE WFID:STO7,LABEL:"",BIT/NR:16,BN.FMT:RI,BYT/NR:2,BYT.OR:LSB,CRVCHK:NONE,ENCDG:ASCII,NR.PT:512,PT.FMT:Y,RHOFACTOR:1.0E+0,RHOPOS:0.0E+0,XINCR:4.0E-12,XMULT:1.5625E-4,XUNIT:SECONDS,XZERO:4.913E-8,YMULT:1.5625E-6,YUNIT:VOLTS,YZERO:0.0E+0,TIME:"14:08:31",DATE:" 2-DEC-98";WFMPRE WFID:STO8,LABEL:"",BIT/NR:16,BN.FMT:RI,BYT/NR:2,BYT.OR:LSB,CRV! CH! K:NONE,ENCDG:ASCII,NR.PT:512,PT.FMT:Y,RHOFACTOR:1.0E+0,RHOPOS:0.0E+0,XINCR:4.0E-12,XMULT:1.5625E-4,XUNIT:SECONDS,XZERO:4.913E-8,YMULT:1.5625E-6,YUNIT:VOLTS,YZERO:0.0E+0,TIME:"14:08:43",DATE:" 2-DEC-98";WFMPRE WFID:STO9,LABEL:"",BIT/NR:16,BN.FMT:RI,BYT/NR:2,BYT.OR:LSB,CRVCHK:NONE,ENCDG:ASCII,NR.PT:512,PT.FMT:Y,RHOFACTOR:1.0E+0,RHOPOS:0.0E+0,XINCR:4.0E-12,XMULT:1.5625E-4,XUNIT:SECONDS,XZERO:4.913E-8,YMULT:1.5625E-6,YUNIT:VOLTS,YZERO:0.0E+0,TIME:"14:09:00",DATE:" 2-DEC-98";WFMPRE WFID:STO10,LABEL:"",BIT/NR:16,BN.FMT:RI,BYT/NR:2,BYT.OR:LSB,CRVCHK:NONE,ENCDG:ASCII,NR.PT:512,PT.FMT:Y,RHOFACTOR:1.0E+0,RHOPOS:0.0E+0,XINCR:4.0E-12,XMULT:1.5625E-4,XUNIT:SECONDS,XZERO:4.913E-8,YMULT:1.5625E-6,YUNIT:VOLTS,YZERO:0.0E+0,TIME:"14:09:19",DATE:" 2-DEC-98";WFMPRE WFID:STO11,LABEL:"",BIT/NR:16,BN.FMT:RI,BYT/NR:2,BYT.OR:LSB,CRVCHK:NONE,ENCDG:ASCII,NR.PT:512,PT.FMT:Y,RHOFACTOR:1.0E+0,RHOPOS:0.0E+0,XINCR:4.0E-12,XMULT:1.5625E-4,XUNIT:SECONDS,XZERO:4.913E-8,YMULT:1.5625E-6,YUNIT:VOLTS,YZERO:0.0E+0! ,T! IME:"14:09:36",DATE:" 2-DEC-98";WFMPRE WFID:STO12,LABEL:"",BIT/NR:16,BN.FMT:RI,BYT/NR:2,BYT.OR:LSB,CRVCHK:NONE,ENCDG:ASCII,NR.PT:512,PT.FMT:Y,RHOFACTOR:1.0E+0,RHOPOS:0.0E+0,XINCR:4.0E-12,XMULT:1.5625E-4,XUNIT:SECONDS,XZERO:4.913E-8,YMULT:1.5625E-6,YUNIT:VOLTS,YZERO:0.0E+0,TIME:"14:09:50",DATE:" 2-DEC-98";WFMPRE WFID:STO13,LABEL:"",BIT/NR:16,BN.FMT:RI,BYT/NR:2,BYT.OR:LSB,CRVCHK:NONE,ENCDG:ASCII,NR.PT:512,PT.FMT:Y,RHOFACTOR:1.0E+0,RHOPOS:0.0E+0,XINCR:4.0E-12,XMULT:1.5625E-4,XUNIT:SECONDS,XZERO:4.913E-8,YMULT:1.5625E-6,YUNIT:VOLTS,YZERO:0.0E+0,TIME:"14:10:06",DATE:" 2-DEC-98";WFMPRE WFID:STO14,LABEL:"",BIT/NR:16,BN.FMT:RI,BYT/NR:2,BYT.OR:LSB,CRVCHK:NONE,ENCDG:ASCII,NR.PT:512,PT.FMT:Y,RHOFACTOR:1.0E+0,RHOPOS:0.0E+0,XINCR:4.0E-12,XMULT:1.5625E-4,XUNIT:SECONDS,XZERO:4.913E-8,YMULT:1.5625E-6,YUNIT:VOLTS,YZERO:0.0E+0,TIME:"14:10:22",DATE:" 2-DEC-98";WFMPRE WFID:STO15,LABEL:"",BIT/NR:16,BN.FMT:RI,BYT/NR:2,BYT.OR:LSB,CRVCHK:NONE,ENCDG:ASCII,NR.PT:512,PT.FMT:Y,RHOFACTOR:1.0E+0,RHOPOS:0! .0! E+0,XINCR:4.0E-12,XMULT:1.5625E-4,XUNIT:SECONDS,XZERO:4.913E-8,YMULT:1.5625E-6,YUNIT:VOLTS,YZERO:0.0E+0,TIME:"14:10:43",DATE:" 2-DEC-98";WFMPRE WFID:STO16,LABEL:"",BIT/NR:16,BN.FMT:RI,BYT/NR:2,BYT.OR:LSB,CRVCHK:NONE,ENCDG:ASCII,NR.PT:512,PT.FMT:Y,RHOFACTOR:1.0E+0,RHOPOS:0.0E+0,XINCR:4.0E-12,XMULT:1.5625E-4,XUNIT:SECONDS,XZERO:4.913E-8,YMULT:1.5625E-6,YUNIT:VOLTS,YZERO:0.0E+0,TIME:"14:11:02",DATE:" 2-DEC-98";WFMPRE WFID:STO17,LABEL:"",BIT/NR:16,BN.FMT:RI,BYT/NR:2,BYT.OR:LSB,CRVCHK:NONE,ENCDG:ASCII,NR.PT:512,PT.FMT:Y,RHOFACTOR:1.0E+0,RHOPOS:0.0E+0,XINCR:4.0E-12,XMULT:1.5625E-4,XUNIT:SECONDS,XZERO:4.913E-8,YMULT:1.5625E-6,YUNIT:VOLTS,YZERO:0.0E+0,TIME:"14:11:21",DATE:" 2-DEC-98";WFMPRE WFID:STO18,LABEL:"",BIT/NR:16,BN.FMT:RI,BYT/NR:2,BYT.OR:LSB,CRVCHK:NONE,ENCDG:ASCII,NR.PT:512,PT.FMT:Y,RHOFACTOR:1.0E+0,RHOPOS:0.0E+0,XINCR:4.0E-12,XMULT:1.5625E-4,XUNIT:SECONDS,XZERO:4.913E-8,YMULT:1.5625E-6,YUNIT:VOLTS,YZERO:0.0E+0,TIME:"14:11:41",DATE:" 2-DEC-98";WFMPRE WFID:STO19,LABEL:"",BIT! /N! R:16,BN.FMT:RI,BYT/NR:2,BYT.OR:LSB,CRVCHK:NONE,ENCDG:ASCII,NR.PT:512,PT.FMT:Y,RHOFACTOR:1.0E+0,RHOPOS:0.0E+0,XINCR:4.0E-12,XMULT:1.5625E-4,XUNIT:SECONDS,XZERO:4.913E-8,YMULT:1.5625E-6,YUNIT:VOLTS,YZERO:0.0E+0,TIME:"14:11:57",DATE:" 2-DEC-98";WFMPRE WFID:STO20,LABEL:"",BIT/NR:16,BN.FMT:RI,BYT/NR:2,BYT.OR:LSB,CRVCHK:NONE,ENCDG:ASCII,NR.PT:512,PT.FMT:Y,RHOFACTOR:1.0E+0,RHOPOS:0.0E+0,XINCR:4.0E-12,XMULT:1.5625E-4,XUNIT:SECONDS,XZERO:4.913E-8,YMULT:1.5625E-6,YUNIT:VOLTS,YZERO:0.0E+0,TIME:"14:12:47",DATE:" 2-DEC-98";WFMPRE WFID:STO21,LABEL:"",BIT/NR:16,BN.FMT:RI,BYT/NR:2,BYT.OR:LSB,CRVCHK:NONE,ENCDG:ASCII,NR.PT:512,PT.FMT:Y,RHOFACTOR:1.0E+0,RHOPOS:0.0E+0,XINCR:4.0E-12,XMULT:1.5625E-4,XUNIT:SECONDS,XZERO:4.913E-8,YMULT:1.5625E-6,YUNIT:VOLTS,YZERO:0.0E+0,TIME:"14:13:07",DATE:" 2-DEC-98";WFMPRE WFID:STO22,LABEL:"",BIT/NR:16,BN.FMT:RI,BYT/NR:2,BYT.OR:LSB,CRVCHK:NONE,ENCDG:ASCII,NR.PT:512,PT.FMT:Y,RHOFACTOR:1.0E+0,RHOPOS:0.0E+0,XINCR:4.0E-12,XMULT:1.5625E-4,XUNIT:SECONDS,XZERO:4.913E-8! ,Y! MULT:1.5625E-6,YUNIT:VOLTS,YZERO:0.0E+0,TIME:"14:13:33",DATE:" 2-DEC-98";WFMPRE WFID:STO23,LABEL:"",BIT/NR:16,BN.FMT:RI,BYT/NR:2,BYT.OR:LSB,CRVCHK:NONE,ENCDG:ASCII,NR.PT:512,PT.FMT:Y,RHOFACTOR:1.0E+0,RHOPOS:0.0E+0,XINCR:4.0E-12,XMULT:1.5625E-4,XUNIT:SECONDS,XZERO:4.913E-8,YMULT:1.5625E-6,YUNIT:VOLTS,YZERO:0.0E+0,TIME:"14:14:12",DATE:" 2-DEC-98";WFMPRE WFID:STO24,LABEL:"",BIT/NR:16,BN.FMT:RI,BYT/NR:2,BYT.OR:LSB,CRVCHK:NONE,ENCDG:ASCII,NR.PT:512,PT.FMT:Y,RHOFACTOR:1.0E+0,RHOPOS:0.0E+0,XINCR:4.0E-12,XMULT:1.5625E-4,XUNIT:SECONDS,XZERO:4.913E-8,YMULT:1.5625E-6,YUNIT:VOLTS,YZERO:0.0E+0,TIME:"14:16:53",DATE:" 2-DEC-98";WFMPRE WFID:STO25,LABEL:"",BIT/NR:16,BN.FMT:RI,BYT/NR:2,BYT.OR:LSB,CRVCHK:NONE,ENCDG:ASCII,NR.PT:512,PT.FMT:Y,RHOFACTOR:1.0E+0,RHOPOS:0.0E+0,XINCR:4.0E-12,XMULT:1.5625E-4,XUNIT:SECONDS,XZERO:4.913E-8,YMULT:1.5625E-6,YUNIT:VOLTS,YZERO:0.0E+0,TIME:"14:17:09",DATE:" 2-DEC-98";WFMPRE WFID:STO26,LABEL:"",BIT/NR:16,BN.FMT:RI,BYT/NR:2,BYT.OR:LSB,CRVCHK:NONE,ENCDG:ASCII,NR.! PT! :512,PT.FMT:Y,RHOFACTOR:1.0E+0,RHOPOS:0.0E+0,XINCR:4.0E-12,XMULT:1.5625E-4,XUNIT:SECONDS,XZERO:4.913E-8,YMULT:1.5625E-6,YUNIT:VOLTS,YZERO:0.0E+0,TIME:"14:17:27",DATE:" 2-DEC-98";WFMPRE WFID:STO27,LABEL:"",BIT/NR:16,BN.FMT:RI,BYT/NR:2,BYT.OR:LSB,CRVCHK:NONE,ENCDG:ASCII,NR.PT:512,PT.FMT:Y,RHOFACTOR:1.0E+0,RHOPOS:0.0E+0,XINCR:4.0E-12,XMULT:1.5625E-4,XUNIT:SECONDS,XZERO:4.913E-8,YMULT:1.5625E-6,YUNIT:VOLTS,YZERO:0.0E+0,TIME:"14:17:49",DATE:" 2-DEC-98";WFMPRE WFID:STO28,LABEL:"",BIT/NR:16,BN.FMT:RI,BYT/NR:2,BYT.OR:LSB,CRVCHK:NONE,ENCDG:ASCII,NR.PT:512,PT.FMT:Y,RHOFACTOR:1.0E+0,RHOPOS:0.0E+0,XINCR:4.0E-12,XMULT:1.5625E-4,XUNIT:SECONDS,XZERO:4.913E-8,YMULT:1.5625E-6,YUNIT:VOLTS,YZERO:0.0E+0,TIME:"14:18:19",DATE:" 2-DEC-98";WFMPRE WFID:STO29,LABEL:"",BIT/NR:16,BN.FMT:RI,BYT/NR:2,BYT.OR:LSB,CRVCHK:NONE,ENCDG:ASCII,NR.PT:512,PT.FMT:Y,RHOFACTOR:1.0E+0,RHOPOS:0.0E+0,XINCR:4.0E-12,XMULT:1.5625E-4,XUNIT:SECONDS,XZERO:4.913E-8,YMULT:1.5625E-6,YUNIT:VOLTS,YZERO:0.0E+0,TIME:"14:18:42",DATE:"! 2! -DEC-98";WFMPRE WFID:STO30,LABEL:"",BIT/NR:16,BN.FMT:RI,BYT/NR:2,BYT.OR:LSB,CRVCHK:NONE,ENCDG:ASCII,NR.PT:512,PT.FMT:Y,RHOFACTOR:1.0E+0,RHOPOS:0.0E+0,XINCR:4.0E-12,XMULT:1.5625E-4,XUNIT:SECONDS,XZERO:4.913E-8,YMULT:1.5625E-6,YUNIT:VOLTS,YZERO:0.0E+0,TIME:"14:19:07",DATE:" 2-DEC-98";WFMPRE WFID:STO31,LABEL:"",BIT/NR:16,BN.FMT:RI,BYT/NR:2,BYT.OR:LSB,CRVCHK:NONE,ENCDG:ASCII,NR.PT:512,PT.FMT:Y,RHOFACTOR:1.0E+0,RHOPOS:0.0E+0,XINCR:4.0E-12,XMULT:1.5625E-4,XUNIT:SECONDS,XZERO:4.913E-8,YMULT:1.5625E-6,YUNIT:VOLTS,YZERO:0.0E+0,TIME:"14:19:29",DATE:" 2-DEC-98";WFMPRE WFID:STO32,LABEL:"",BIT/NR:16,BN.FMT:RI,BYT/NR:2,BYT.OR:LSB,CRVCHK:NONE,ENCDG:ASCII,NR.PT:512,PT.FMT:Y,RHOFACTOR:1.0E+0,RHOPOS:0.0E+0,XINCR:4.0E-12,XMULT:1.5625E-4,XUNIT:SECONDS,XZERO:4.913E-8,YMULT:1.5625E-6,YUNIT:VOLTS,YZERO:0.0E+0,TIME:"14:19:51",DATE:" 2-DEC-98";WFMPRE WFID:STO33,LABEL:"",BIT/NR:16,BN.FMT:RI,BYT/NR:2,BYT.OR:LSB,CRVCHK:NONE,ENCDG:ASCII,NR.PT:512,PT.FMT:Y,RHOFACTOR:1.0E+0,RHOPOS:0.0E+0,XINCR:4.0E-12,XMU! LT! :1.5625E-4,XUNIT:SECONDS,XZERO:4.913E-8,YMULT:1.5625E-6,YUNIT:VOLTS,YZERO:0.0E+0,TIME:"14:20:36",DATE:" 2-DEC-98";WFMPRE WFID:STO34,LABEL:"",BIT/NR:16,BN.FMT:RI,BYT/NR:2,BYT.OR:LSB,CRVCHK:NONE,ENCDG:ASCII,NR.PT:512,PT.FMT:Y,RHOFACTOR:1.0E+0,RHOPOS:0.0E+0,XINCR:4.0E-12,XMULT:1.5625E-4,XUNIT:SECONDS,XZERO:4.913E-8,YMULT:1.5625E-6,YUNIT:VOLTS,YZERO:0.0E+0,TIME:"14:22:39",DATE:" 2-DEC-98";WFMPRE WFID:STO35,LABEL:"",BIT/NR:16,BN.FMT:RI,BYT/NR:2,BYT.OR:LSB,CRVCHK:NONE,ENCDG:ASCII,NR.PT:512,PT.FMT:Y,RHOFACTOR:1.0E+0,RHOPOS:0.0E+0,XINCR:4.0E-12,XMULT:1.5625E-4,XUNIT:SECONDS,XZERO:4.913E-8,YMULT:1.5625E-6,YUNIT:VOLTS,YZERO:0.0E+0,TIME:"14:23:24",DATE:" 2-DEC-98";WFMPRE WFID:STO36,LABEL:"",BIT/NR:16,BN.FMT:RI,BYT/NR:2,BYT.OR:LSB,CRVCHK:NONE,ENCDG:ASCII,NR.PT:512,PT.FMT:Y,RHOFACTOR:1.0E+0,RHOPOS:0.0E+0,XINCR:4.0E-12,XMULT:1.5625E-4,XUNIT:SECONDS,XZERO:4.913E-8,YMULT:1.5625E-6,YUNIT:VOLTS,YZERO:0.0E+0,TIME:"14:23:52",DATE:" 2-DEC-98";WFMPRE WFID:STO37,LABEL:"",BIT/NR:16,BN.FMT:RI,BYT/NR! :2! ,BYT.OR:LSB,CRVCHK:NONE,ENCDG:ASCII,NR.PT:512,PT.FMT:Y,RHOFACTOR:1.0E+0,RHOPOS:0.0E+0,XINCR:4.0E-12,XMULT:1.5625E-4,XUNIT:SECONDS,XZERO:4.913E-8,YMULT:1.5625E-6,YUNIT:VOLTS,YZERO:0.0E+0,TIME:"14:23:55",DATE:" 2-DEC-98" --------------3C6B6947244B-- From icon-group-sender Mon Dec 7 08:37:44 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA08739 for icon-group-addresses; Mon, 7 Dec 1998 08:37:37 -0700 (MST) Message-Id: <199812071537.IAA08739@baskerville.CS.Arizona.EDU> To: icon-group@optima.CS.Arizona.EDU Date: Sat, 5 Dec 1998 16:29:14 -0600 From: "Philip Pesek" Subject: Internet Programming with Icon Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO I have a question, does the icon language have support for internet programming either under unix or with winsock or something like that? -Phil "COBRA" Pesek From icon-group-sender Mon Dec 7 08:37:57 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA08774 for icon-group-addresses; Mon, 7 Dec 1998 08:37:51 -0700 (MST) Message-Id: <199812071537.IAA08774@baskerville.CS.Arizona.EDU> Date: Mon, 7 Dec 1998 07:38:51 -0700 From: Ralph Griswold To: icon-group Subject: Icon CD-ROM Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO A CD-ROM for Icon now is available. Follow the first link on the Icon home page at http://www.cs.arizona.edu/icon/ From icon-group-sender Mon Dec 7 14:37:17 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id OAA27718 for icon-group-addresses; Mon, 7 Dec 1998 14:37:00 -0700 (MST) Message-Id: <199812072137.OAA27718@baskerville.CS.Arizona.EDU> Date: Mon, 7 Dec 1998 09:01:59 -0700 From: swampler@noao.edu (Steve Wampler) Subject: Re: Past Keyword / Coexpr Help To: evans@gte.net Cc: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO You can write your own string analysis function to implement past(). As I understand what you want, the following would work: procedure past(s) suspend (tab(find(s)),match(s)) end I'm not convinced you really want a co-expression in your 2nd question, but need to think about that some. No doubt someone else will have a good solution soon! -- Steve Wampler - swampler@gemini.edu [Gemini 8m Telescopes Project (under AURA)] The gods that smiled at your birth are now laughing openly. (Fortune Cookie) From icon-group-sender Mon Dec 7 14:39:07 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id OAA28761 for icon-group-addresses; Mon, 7 Dec 1998 14:39:00 -0700 (MST) Message-Id: <199812072139.OAA28761@baskerville.CS.Arizona.EDU> From: "Nevin Liber" To: Cc: "MJE" Subject: RE: Past Keyword / Coexpr Help Date: Mon, 7 Dec 1998 10:12:21 -0600 X-Priority: 3 (Normal) X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO > The scanning mechanism I want would perhaps be called "past", as in > > numberchars := (&digits ++ 'e' ++ 'E' ++ '+' ++ '-' ++ '.') > string ? > { > tab(past("substring")) > result := real(tab(many(numberchars))) > } It has find(), and it is fairly trivial to write past() using find. Here you go: procedure past(s1, s2, i1, i2) suspend find(s1, s2, i1, i2) + *s1 end __ Nevin ":-)" Liber (312) 855-1000 x199 National Systems Corporation 414 North Orleans Street, Suite 501 Chicago, IL 60610-4490 fax: (312) 222-1605 From icon-group-sender Mon Dec 7 14:40:25 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id OAA29765 for icon-group-addresses; Mon, 7 Dec 1998 14:40:16 -0700 (MST) Message-Id: <199812072140.OAA29765@baskerville.CS.Arizona.EDU> Date: Mon, 07 Dec 1998 10:36:01 -0600 From: MJE To: icon-group@optima.CS.Arizona.EDU Subject: Re: Past Keyword / Coexpr Help Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO I like Steve Wampler's answer. Since "find" is a generator, presumably this function will also behave as a generator. I would still lobby for the "past" keyword, but no complaints. Mark Steve Wampler wrote: > > You can write your own string analysis function to implement past(). > > As I understand what you want, the following would work: > > procedure past(s) > suspend (tab(find(s)),match(s)) > end > > I'm not convinced you really want a co-expression in your 2nd question, but > need to think about that some. No doubt someone else will have a good > solution soon! > > -- > Steve Wampler - swampler@gemini.edu [Gemini 8m Telescopes Project (under AURA)] > The gods that smiled at your birth are now laughing openly. (Fortune Cookie) Nevin Liber wrote: > > > The scanning mechanism I want would perhaps be called "past", as in > > > > numberchars := (&digits ++ 'e' ++ 'E' ++ '+' ++ '-' ++ '.') > > string ? > > { > > tab(past("substring")) > > result := real(tab(many(numberchars))) > > } > > It has find(), and it is fairly trivial to write past() using find. Here > you go: > > procedure past(s1, s2, i1, i2) > > suspend find(s1, s2, i1, i2) + *s1 > > end > __ > Nevin ":-)" Liber (312) 855-1000 x199 > > National Systems Corporation > 414 North Orleans Street, Suite 501 > Chicago, IL 60610-4490 > fax: (312) 222-1605 > From icon-group-sender Mon Dec 7 14:40:40 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id OAA29911 for icon-group-addresses; Mon, 7 Dec 1998 14:40:32 -0700 (MST) Message-Id: <199812072140.OAA29911@baskerville.CS.Arizona.EDU> Date: Mon, 7 Dec 1998 10:30:23 -0700 From: Gregg Townsend To: Paul_A._Sue@ismbc.com, icon-group@optima.CS.Arizona.EDU Subject: Re: Icon to C interface Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO From: "Paul A. Sue" To: icon-group@optima.CS.Arizona.EDU Date: Thu, 3 Dec 1998 15:05:19 -0800 ...I would like to know if there is a way to interface Icon with C (i.e. call C functions from Icon, or call an Icon procedure from C) ?? It is fairly easy to call C functions from Icon under Unix if you're willing to write the functions specifically to interface to Icon. See the "dynamic loading" section of http://www.cs.arizona.edu/icon/docs/ipd240.htm (If anyone has figured out how to make this work under IBM AIX 4.2, I'd like to hear from them; it doesn't like my shared library. ) There's no easy way to call Icon code from C other than by communication with an Icon program running in a separate process. (System(), pipe, etc.) --------------------------------------------------------------------------- Gregg Townsend Gould-Simpson Building gmt@cs.arizona.edu Staff Scientist 1040 E. 4th St. 32 13 45N 110 57 16W Dept. of Computer Science PO Box 210077 tel: +1 520 621 4325 The University of Arizona Tucson, AZ 85721-0077 fax: +1 520 621 4246 From icon-group-sender Mon Dec 7 16:28:29 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA17520 for icon-group-addresses; Mon, 7 Dec 1998 16:27:42 -0700 (MST) Message-Id: <199812072327.QAA17520@baskerville.CS.Arizona.EDU> To: icon-group@optima.CS.Arizona.EDU Date: 7 Dec 1998 16:41:36 -0500 From: "Nevin Liber" Subject: RE: Past Keyword / Coexpr Help Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO > The scanning mechanism I want would perhaps be called "past", as in > > numberchars := (&digits ++ 'e' ++ 'E' ++ '+' ++ '-' ++ '.') > string ? > { > tab(past("substring")) > result := real(tab(many(numberchars))) > } It has find(), and it is fairly trivial to write past() using find. Here you go: procedure past(s1, s2, i1, i2) suspend find(s1, s2, i1, i2) + *s1 end __ Nevin ":-)" Liber (312) 855-1000 x199 National Systems Corporation 414 North Orleans Street, Suite 501 Chicago, IL 60610-4490 fax: (312) 222-1605 From icon-group-sender Mon Dec 7 17:04:40 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id RAA19280 for icon-group-addresses; Mon, 7 Dec 1998 17:02:55 -0700 (MST) Message-Id: <199812080002.RAA19280@baskerville.CS.Arizona.EDU> Date: Mon, 7 Dec 1998 14:59:00 -0700 From: swampler@noao.edu (Steve Wampler) Subject: Re: Past Keyword / Coexpr Help To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO MJE wrote: > I like Steve Wampler's answer. Since "find" is a generator, presumably > this function will also behave as a generator. I would still lobby for > the "past" keyword, but no complaints. > > Mark > > > Steve Wampler wrote: > > > > You can write your own string analysis function to implement past(). > > > > As I understand what you want, the following would work: > > > > procedure past(s) > > suspend (tab(find(s)),match(s)) > > end > > > > Nevin Liber wrote: > > > > > > It has find(), and it is fairly trivial to write past() using find. Here > > you go: > > > > procedure past(s1, s2, i1, i2) > > > > suspend find(s1, s2, i1, i2) + *s1 > > > > end The advantage Nevin's has is that it behaves exactly the same as the other string analysis functions (i.e. you can supply the last three arguments and use it outside of string scanning). It's probably slightly faster as well, but I doubt the difference would be noticable to most of us. A compromise is: procedure past(s1,s2,i,j) suspend (find(s1,s2,i,j),match(s1)) end -- Steve Wampler - swampler@gemini.edu [Gemini 8m Telescopes Project (under AURA)] The gods that smiled at your birth are now laughing openly. (Fortune Cookie) From icon-group-sender Mon Dec 7 17:09:20 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id RAA19494 for icon-group-addresses; Mon, 7 Dec 1998 17:07:49 -0700 (MST) Message-Id: <199812080007.RAA19494@baskerville.CS.Arizona.EDU> Date: Mon, 7 Dec 1998 15:06:47 -0700 From: Gregg Townsend To: hgs@dmu.ac.uk, icon-group@optima.CS.Arizona.EDU Subject: Re: Building on Solaris 2.5.1 sparc gcc Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO From: hgs@dmu.ac.uk (Hugh Sasse) Date: 4 Dec 98 18:54:10 GMT ... make X-Configure name=sun_gcc .. ../h/../h/../xpm/xpm.h:20: X11/Xlib.h: No such file or directory ... Try editing the *.hdr files in config/unix/sun_gcc and adding "-I/usr/openwin/include" to those CFLAGS lines that don't already have it. Then rerun "make X-Configure" and rebuild. --------------------------------------------------------------------------- Gregg Townsend Gould-Simpson Building gmt@cs.arizona.edu Staff Scientist 1040 E. 4th St. 32 13 45N 110 57 16W Dept. of Computer Science PO Box 210077 tel: +1 520 621 4325 The University of Arizona Tucson, AZ 85721-0077 fax: +1 520 621 4246 From icon-group-sender Mon Dec 7 17:49:28 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id RAA20752 for icon-group-addresses; Mon, 7 Dec 1998 17:49:13 -0700 (MST) Message-Id: <199812080049.RAA20752@baskerville.CS.Arizona.EDU> Date: Mon, 7 Dec 1998 17:50:17 -0600 From: Clinton Jeffery To: evans@gte.net CC: icon-group@optima.CS.Arizona.EDU Subject: Re: Past Keyword / Coexpr Help Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO SW> procedure past(s) SW> suspend (tab(find(s)),match(s)) SW> end NL> procedure past(s1, s2, i1, i2) NL> suspend find(s1, s2, i1, i2) + *s1 NL> end MEvans> I like Steve Wampler's answer. Since "find" is a generator, MEvans> presumably this function will also behave as a generator. I would MEvans> still lobby for the "past" keyword, but no complaints. Gee, both of these solutions behave just fine as a generator. Nevin's looks more efficient and works outside of string scanning environments. :-) For the record, I've wanted a past() function before, as well. My code is often riddled with find(s) + *s ... Clint From icon-group-sender Tue Dec 8 10:05:08 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id KAA27880 for icon-group-addresses; Tue, 8 Dec 1998 10:05:00 -0700 (MST) Message-Id: <199812081705.KAA27880@baskerville.CS.Arizona.EDU> Date: Sat, 05 Dec 1998 20:15:10 -0800 From: Michael Adams To: icon-group@optima.CS.Arizona.EDU Subject: Window names Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Hi, The CopyArea(W1,W2,x1,y1,w,h,x2,y2) function has the ability to copy a rectangular area from one window to another, if W1 and W2 are different windows. However, I can't find any information on how to name windows so that you can call then by W1 or W2... So how do I know what to call the windows by? Could you include an example please? Also, how much in $US does your CD ROM cost in shipping etc? Yours, Michael Adams. mailto:adams@flexibledoors.co.nz P.S. Icon is really good, and simple! I like it!!! From icon-group-sender Tue Dec 8 10:06:37 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id KAA28737 for icon-group-addresses; Tue, 8 Dec 1998 10:06:28 -0700 (MST) Message-Id: <199812081706.KAA28737@baskerville.CS.Arizona.EDU> Date: Tue, 08 Dec 1998 03:52:39 -0600 From: MJE To: icon-group@optima.CS.Arizona.EDU Subject: Re: Past Keyword / Coexpr Help Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Clinton Jeffery wrote: > > SW> procedure past(s) > SW> suspend (tab(find(s)),match(s)) > SW> end > > NL> procedure past(s1, s2, i1, i2) > NL> suspend find(s1, s2, i1, i2) + *s1 > NL> end > > MEvans> I like Steve Wampler's answer. Since "find" is a generator, > MEvans> presumably this function will also behave as a generator. I would > MEvans> still lobby for the "past" keyword, but no complaints. > > Gee, both of these solutions behave just fine as a generator. Nevin's > looks more efficient and works outside of string scanning environments. :-) > > For the record, I've wanted a past() function before, as well. My code is > often riddled with find(s) + *s ... > > Clint What everyone is missing about procedures-that-do-the-job is the speed consideration. Think about embedding either procedure in a deep inner loop of some kind. At that point, it is much preferable to have a keyword, which (a) avoids any overhead of procedure calling, (b) doesn't have to both find and then match the same text (redundancy), (c) simplifies the code readability So with Clint I must say that the keyword is still a good idea. Thanks for the advice however, it gets me off the dime. Mark From icon-group-sender Tue Dec 8 10:06:54 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id KAA28763 for icon-group-addresses; Tue, 8 Dec 1998 10:06:47 -0700 (MST) Message-Id: <199812081706.KAA28763@baskerville.CS.Arizona.EDU> Date: Tue, 8 Dec 1998 08:43:55 -0700 From: Gregg Townsend To: icon-group@optima.CS.Arizona.EDU, ppesek@nyx.net Subject: Re: Internet Programming with Icon Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO From: "Philip Pesek" I have a question, does the icon language have support for internet programming either under unix or with winsock or something like that? Not really. There's some loadable C code for Unix in the Icon program library that lets a client open a connection to a server, but that's about it. --------------------------------------------------------------------------- Gregg Townsend Gould-Simpson Building gmt@cs.arizona.edu Staff Scientist 1040 E. 4th St. 32 13 45N 110 57 16W Dept. of Computer Science PO Box 210077 tel: +1 520 621 4325 The University of Arizona Tucson, AZ 85721-0077 fax: +1 520 621 4246 From icon-group-sender Tue Dec 8 13:05:40 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id NAA01207 for icon-group-addresses; Tue, 8 Dec 1998 13:04:36 -0700 (MST) Message-Id: <199812082004.NAA01207@baskerville.CS.Arizona.EDU> Date: Tue, 8 Dec 1998 10:19:56 -0700 From: swampler@noao.edu (Steve Wampler) Subject: Re: Past Keyword / Coexpr Help To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Sigh - Stick with Nevin's solution, my compromise solution is, itself, compromised. A corrected version is below, but Nevin's is now cleaner as well as faster... procedure past(s1,s2,i,j) suspend (find(s1,s2,i,j),match(s1,s2,i,j)) end -- Steve Wampler - swampler@gemini.edu [Gemini 8m Telescopes Project (under AURA)] The gods that smiled at your birth are now laughing openly. (Fortune Cookie) From icon-group-sender Tue Dec 8 13:08:05 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id NAA01594 for icon-group-addresses; Tue, 8 Dec 1998 13:07:54 -0700 (MST) Message-Id: <199812082007.NAA01594@baskerville.CS.Arizona.EDU> Date: Tue, 8 Dec 1998 10:30:57 -0700 From: swampler@noao.edu (Steve Wampler) Subject: Re: Past Keyword / Coexpr Help To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO MJE wrote: > > > What everyone is missing about procedures-that-do-the-job is the speed > consideration. Think about embedding either procedure in a deep inner > loop of some kind. At that point, it is much preferable to have a > keyword, which > > (a) avoids any overhead of procedure calling, (b) doesn't have to both > find and then match the same text (redundancy), (c) simplifies the code > readability > > So with Clint I must say that the keyword is still a good idea. > > Thanks for the advice however, it gets me off the dime. Uh, you don't mean a keyword, you mean a 'built-in' function. You still have the overhead of procedure calling - there is no difference in the call to a user-supplied procedure and a built-in. You do gain some improvement by implementing past() in C (as a built-in), but you may be surprised at how small that improvement really is! (There are likely to be other factors that dominant the overall time.) Also, Nevin's solution avoids the redundant match, and either solution is called in exactly the same way as a built-in past() would be, so the code readability can't be much different. What might be nice is to develop an IPL 'pack' of useful string analysis procedures, then see which ones might be considered candidates for speed improvements by recoding in C - after gaining experience with their use. -- Steve Wampler - swampler@gemini.edu [Gemini 8m Telescopes Project (under AURA)] The gods that smiled at your birth are now laughing openly. (Fortune Cookie) From icon-group-sender Tue Dec 8 13:23:11 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id NAA03159 for icon-group-addresses; Tue, 8 Dec 1998 13:23:02 -0700 (MST) Message-Id: <199812082023.NAA03159@baskerville.CS.Arizona.EDU> Date: Tue, 8 Dec 98 10:35:49 PST From: Shamim Mohamed To: Gregg Townsend Cc: icon-group@optima.CS.Arizona.EDU, ppesek@nyx.net Subject: Re: Internet Programming with Icon Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Philip Pesek: > does the icon language have support for internet programming either under > unix or with winsock or something like that? Gregg Townsend: > Not really. There's some loadable C code for Unix in the Icon program > library that lets a client open a connection to a server, but that's > about it. A quick plug: Unicon has support for sockets. Patches for Icon 9.3 on Unix are available from http://www.drones.com/unicon/. Most of Unicon has been ported to the Microsoft Windows platform by Clint Jeffery and his students and will be available soon. -s From icon-group-sender Tue Dec 8 16:54:01 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA22086 for icon-group-addresses; Tue, 8 Dec 1998 16:53:54 -0700 (MST) Message-Id: <199812082353.QAA22086@baskerville.CS.Arizona.EDU> To: icon-group@optima.CS.Arizona.EDU Date: 8 Dec 1998 22:21:10 GMT From: espie@liafa.jussieu.fr (Marc Espie) Subject: Re: Internet Programming with Icon Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO In article <199812082018.NAA02933@baskerville.CS.Arizona.EDU>, Gregg Townsend wrote: > From: "Philip Pesek" > I have a question, does the icon language have support for internet > programming either under unix or with winsock or something like that? >Not really. There's some loadable C code for Unix in the Icon program >library that lets a client open a connection to a server, but that's >about it. Not quite. What's the status of unicon ? I just went to see the web page, but it's now one year old, and there isn't even an email address to enquire to... (http://www.drones.com/unicon/) -- Marc Espie |anime, sf, juggling, unicycle, acrobatics, comics... |AmigaOS, OpenBSD, C++, perl, Icon, PostScript... | `real programmers don't die, they just get out of beta' From icon-group-sender Tue Dec 8 16:54:20 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA22113 for icon-group-addresses; Tue, 8 Dec 1998 16:54:12 -0700 (MST) Message-Id: <199812082354.QAA22113@baskerville.CS.Arizona.EDU> Date: Tue, 08 Dec 1998 17:16:16 -0600 From: MJE To: Shamim Mohamed CC: icon-group@optima.CS.Arizona.EDU Subject: Re: Internet Programming with Icon Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Shamim Mohamed wrote: > > Philip Pesek: > > does the icon language have support for internet programming either under > > unix or with winsock or something like that? > > Gregg Townsend: > > Not really. There's some loadable C code for Unix in the Icon program > > library that lets a client open a connection to a server, but that's > > about it. > > A quick plug: Unicon has support for sockets. Patches for Icon 9.3 on Unix > are available from http://www.drones.com/unicon/. Most of Unicon has been > ported to the Microsoft Windows platform by Clint Jeffery and his students > and will be available soon. > > -s I love it -- "inciting me to commit this act of implementation" -- we need more of that around here. Anything that takes the headaches out of Unix is worthwhile. Pretty soon you'll have all those fat-cat sys-admins looking for work, while minimum wage teenage hackers write Icon scripts to replace them. Mark From icon-group-sender Tue Dec 8 16:54:41 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA22144 for icon-group-addresses; Tue, 8 Dec 1998 16:54:34 -0700 (MST) Message-Id: <199812082354.QAA22144@baskerville.CS.Arizona.EDU> Date: Tue, 08 Dec 1998 17:23:12 -0600 From: MJE To: Steve Wampler CC: icon-group@optima.CS.Arizona.EDU Subject: Re: Past Keyword / Coexpr Help Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Steve Wampler wrote: > > MJE wrote: > > > > > > What everyone is missing about procedures-that-do-the-job is the speed > > consideration. Think about embedding either procedure in a deep inner > > loop of some kind. At that point, it is much preferable to have a > > keyword, which > > > > (a) avoids any overhead of procedure calling, (b) doesn't have to both > > find and then match the same text (redundancy), (c) simplifies the code > > readability > > > > So with Clint I must say that the keyword is still a good idea. > > > > Thanks for the advice however, it gets me off the dime. > > Uh, you don't mean a keyword, you mean a 'built-in' function. You still > have the overhead of procedure calling - there is no difference in the > call to a user-supplied procedure and a built-in. The logical requirements are identical but I'm sure you'll grant that C overhead happens much faster than Icon interpreted overhead. I like your idea about an IPL pack. However, you have not incited me to commit an act of implementation. What interests me instead is making Icon parsing available in C language programs. For that I will need to write a bunch of COM objects. That means "Component Object Model" for those not in the know, Microsoft's upgrade to the DLL concept. I have been mulling over this project for a while. A little more mulling, and I might be incited to commit an act of implementation. Mark From icon-group-sender Thu Dec 10 09:02:35 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA05606 for icon-group-addresses; Thu, 10 Dec 1998 08:58:24 -0700 (MST) Message-Id: <199812101558.IAA05606@baskerville.CS.Arizona.EDU> Date: Tue, 08 Dec 1998 17:47:30 -0600 From: MJE To: icon-group@optima.CS.Arizona.EDU Subject: IPD261 Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO How come IPD261 is not available here? http://www.eleves.ens.fr:8080/docs/icon/trs.html 261 deals with the superset of C in which Icon is written. M. From icon-group-sender Thu Dec 10 09:06:07 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id JAA06264 for icon-group-addresses; Thu, 10 Dec 1998 09:04:38 -0700 (MST) Message-Id: <199812101604.JAA06264@baskerville.CS.Arizona.EDU> From: swampler@noao.edu (Steve Wampler) Date: Tue, 8 Dec 1998 18:22:21 MST To: icon-group@optima.CS.Arizona.EDU Subject: Re: Past Keyword / Coexpr Help Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO On Dec 8 at 5:23pm, MJE writes: } Steve Wampler wrote: } > } > ... You still } > have the overhead of procedure calling - there is no difference in the } > call to a user-supplied procedure and a built-in. } } The logical requirements are identical but I'm sure you'll grant that C } overhead happens much faster than Icon interpreted overhead. Well, yes and no. It's the interpreter making the call in both cases, so argument pushing, stack adjustments, etc. are the same. Only after the call stack has been set up does a difference appear and that's not much more than setting the program counter. Once you're in the C routine, things will go faster, but there are still all the type checks and type coercions that take place, plus the decomposition of Icon types into C types and back. All of these happen in either case. The amount of work done differently (i.e. in C instead of Icon) isn't that large of a percentage of the total work being done. Don't be surprised if there isn't that much difference - the 'heart' of the code (find()) is coded in C either way. Still, it would make a good experiment and I'll certainly grant that if you implemented find() in Icon versus calling the C you'd see a difference. } I like your idea about an IPL pack. However, you have not incited me to } commit an act of implementation. What interests me instead is making } Icon parsing available in C language programs. } For that I will need to write a bunch of COM objects. That means } "Component Object Model" for those not in the know, Microsoft's upgrade } to the DLL concept. I have been mulling over this project for a while. } A little more mulling, and I might be incited to commit an act of } implementation. That will be interesting and certainly useful for those of you running under Windows, but not much use to those of us who live in the non-MS world. One thing to keep in mind is that in many Icon programs, the time spent in the interpreter is <10% of the total running time - most of the time is actually spent in C code. We learned that when Cary Coutant wrote a compiler for Icon back in the 70's - the speed up wasn't spectacular. It took Ken Walker's optimizing compiler work to show any significant improvement and even with that there was still a lot of work to be done. -- Steve Wampler - swampler@gemini.edu [Gemini 8m Telescopes Project (under AURA)] The gods that smiled at your birth are now laughing openly. (Fortune Cookie) From icon-group-sender Thu Dec 10 09:16:48 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id JAA07141 for icon-group-addresses; Thu, 10 Dec 1998 09:15:19 -0700 (MST) Message-Id: <199812101615.JAA07141@baskerville.CS.Arizona.EDU> To: icon-group@optima.CS.Arizona.EDU Subject: is icon embaddable Date: Wed, 09 Dec 1998 08:53:01 -0600 From: Mate Wierdl Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO I am not sure I can ask the right question: is it possible to embed icon in another language. An editor program's maintainers try to figure out what program they should try to use as a "configuration" language. I guess they mean as (e)elisp is used in Emacs. The editor is written in C++. They had perl, tcl and python and perhaps scheme as candidates. Thx Mate --- Mate Wierdl | Dept. of Math. Sciences | University of Memphis From icon-group-sender Thu Dec 10 09:20:22 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id JAA07291 for icon-group-addresses; Thu, 10 Dec 1998 09:18:52 -0700 (MST) Message-Id: <199812101618.JAA07291@baskerville.CS.Arizona.EDU> Date: Wed, 09 Dec 1998 16:31:40 -0600 From: MJE To: icon-group@optima.CS.Arizona.EDU Subject: Options File Name Failure Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO The command-line parsing routines in the options library don't handle filenames with spaces. It will unquote a filename enclosed in quote marks, but if a space appears anywhere in the name, then it will become truncated just prior to the space. The code below can be used to test these statements. Mark procedure main(args) obttbl := options(args,"-file:-skip:") every x := key(obttbl) do write(x," : ",obttbl[x]) end From icon-group-sender Thu Dec 10 09:26:03 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id JAA07520 for icon-group-addresses; Thu, 10 Dec 1998 09:24:33 -0700 (MST) Message-Id: <199812101624.JAA07520@baskerville.CS.Arizona.EDU> Date: Wed, 09 Dec 1998 18:49:44 -0600 From: MJE To: icon-group@optima.CS.Arizona.EDU CC: Clinton Jeffery , Steve Wampler Subject: Formatting Reals Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Dumb question. How can I get more digits of precision when writing real numbers? Tangent to that, it would be nice if Icon supported array math, for example the ability to multiply a list of reals by a single real without having to loop across each element. Another example is multiplying two lists of the same length, elementwise. Mark From icon-group-sender Thu Dec 10 09:27:44 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id JAA07759 for icon-group-addresses; Thu, 10 Dec 1998 09:26:14 -0700 (MST) Message-Id: <199812101626.JAA07759@baskerville.CS.Arizona.EDU> Date: Thu, 10 Dec 1998 15:00:08 +1300 (NZDT) From: "Richard A. O'Keefe" To: evans@gte.net, icon-group@optima.CS.Arizona.EDU Subject: Re: Past Keyword / Coexpr Help Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO What everyone is missing about procedures-that-do-the-job is the speed consideration. Think about embedding either procedure in a deep inner loop of some kind. At that point, it is much preferable to have a keyword, which (a) avoids any overhead of procedure calling, (b) doesn't have to both find and then match the same text (redundancy), (c) simplifies the code readability Concerning (a), just what _is_ the procedure call overhead? It's only worth worrying about if (1) it is large compared with the useful work done (is it large?) (2) the compiler is unable to expand calls to it in-line (is it unable?) (3) there's nothing else going on in that loop with worse overheads. Concerning (c), I note that realistic programming languages have to deal with huge libraries these days. Not the current UNIX interface (the Single UNIX Specification one) but the _previous_ one was called Spec1170 because it had 1170 functions in the interface. Windows has even more. If procedure calls are unreadable, then heaven help us. Concerning (b), is this the _only_ situation where that problem comes up? I don't think so. Just how many keywords are we going to need if we try to solve them all by keywords? From icon-group-sender Thu Dec 10 09:31:40 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id JAA07911 for icon-group-addresses; Thu, 10 Dec 1998 09:29:57 -0700 (MST) Message-Id: <199812101629.JAA07911@baskerville.CS.Arizona.EDU> Date: Wed, 9 Dec 1998 19:04:18 -0700 From: Gregg Townsend To: adams@flexibledoors.co.nz, icon-group@optima.CS.Arizona.EDU Subject: Re: Window names Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO From: Michael Adams The CopyArea(W1,W2,x1,y1,w,h,x2,y2) function has the ability to copy a rectangular area from one window to another, if W1 and W2 are different windows. However, I can't find any information on how to name windows... W1 and W2 are data values of type "window". You'd do something like this: W1 := WOpen(...) W2 := WOpen(...) ... CopyArea(W1,W2,...) All graphics procedures accept window argument like W1 and W2, but they're normally omitted when there's only one window open. --------------------------------------------------------------------------- Gregg Townsend Gould-Simpson Building gmt@cs.arizona.edu Staff Scientist 1040 E. 4th St. 32 13 45N 110 57 16W Dept. of Computer Science PO Box 210077 tel: +1 520 621 4325 The University of Arizona Tucson, AZ 85721-0077 fax: +1 520 621 4246 From icon-group-sender Thu Dec 10 09:33:34 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id JAA08163 for icon-group-addresses; Thu, 10 Dec 1998 09:32:04 -0700 (MST) Message-Id: <199812101632.JAA08163@baskerville.CS.Arizona.EDU> Date: Wed, 09 Dec 1998 20:03:16 -0600 From: MJE To: icon-group@optima.CS.Arizona.EDU Subject: Re: Formatting Reals Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Everyone is picking me apart for my humble suggestion. Clint likes it, that will be my consolation prize. Let me move on. It appears that we have a much more pressing need in Icon than a "past" keyword. That is, intrinsic calls to format numbers. I am trying to process spreadsheet data and am finding it impossible to get real numbers formatted without a lot of overhead in Icon. Icon also fails to clarify whether internal reals are single or double. I guess I'll have to examine the source. If there is to be only one type of real, it should be double precision. The Icon libraries for printf-like formatting are "printf" and "numbers" but both of them involve interpreted string scanning. How silly: A string scanning language that can't format numbers intrinsically. All it would take is a direct pass-through to C library printf capability. So it looks to me like Icon desperately needs some numeric formatting capability. I can live without the "past" intrinsic, but I'll be in a rocking chair before my need for number formatting dies away. Has anyone written a Windows DLL to give access to C's printf? Mark Richard A. O'Keefe wrote: > > What everyone is missing about procedures-that-do-the-job is the speed > consideration. Think about embedding either procedure in a deep inner > loop of some kind. At that point, it is much preferable to have a > keyword, which > > (a) avoids any overhead of procedure calling, > > (b) doesn't have to both find and then match the same text > (redundancy), > > (c) simplifies the code readability > > Concerning (a), just what _is_ the procedure call overhead? > It's only worth worrying about if > (1) it is large compared with the useful work done (is it large?) > (2) the compiler is unable to expand calls to it in-line (is it unable?) > (3) there's nothing else going on in that loop with worse overheads. > > Concerning (c), I note that realistic programming languages have to deal > with huge libraries these days. Not the current UNIX interface (the > Single UNIX Specification one) but the _previous_ one was called Spec1170 > because it had 1170 functions in the interface. Windows has even more. > If procedure calls are unreadable, then heaven help us. > > Concerning (b), is this the _only_ situation where that problem comes > up? I don't think so. Just how many keywords are we going to need if > we try to solve them all by keywords? From icon-group-sender Thu Dec 10 09:35:17 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id JAA09221 for icon-group-addresses; Thu, 10 Dec 1998 09:33:48 -0700 (MST) Message-Id: <199812101633.JAA09221@baskerville.CS.Arizona.EDU> Date: Thu, 10 Dec 1998 09:28:56 -0700 From: swampler@noao.edu (Steve Wampler) Subject: Re: is icon embaddable To: mw@wierdlmpc.msci.memphis.edu Cc: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Mate Wierdl wrote: > I am not sure I can ask the right question: is it possible to embed > icon in another language. An editor program's maintainers try to > figure out what program they should try to use as a "configuration" > language. I guess they mean as (e)elisp is used in Emacs. The editor > is written in C++. They had perl, tcl and python and perhaps scheme > as candidates. Mate - A *long* time ago, William Mitchell (now whm@newmonics.com) wrote 'ice' - Icon Embedded in Emacs, where Icon replaced LISP as the configuration language. So, yes, what you want to do is possible. Perhaps William remembers enough to provide some pointers... -- Steve Wampler - swampler@gemini.edu [Gemini 8m Telescopes Project (under AURA)] The gods that smiled at your birth are now laughing openly. (Fortune Cookie) From icon-group-sender Thu Dec 10 17:11:13 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id RAA07859 for icon-group-addresses; Thu, 10 Dec 1998 17:10:36 -0700 (MST) Message-Id: <199812110010.RAA07859@baskerville.CS.Arizona.EDU> Date: Thu, 10 Dec 1998 12:43:24 -0500 (EST) From: "R. Clayton" To: icon-group@optima.CS.Arizona.EDU Subject: Plus, also, too. Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO I'd just like to say a few words on behalf of our forgotten friends, the regular expressions: ma cat re.icn link regexp procedure main() local pat, cnt, l pat := RePat("(XMULT|XZERO|YMULT|YZERO):([0-9]+\.[0-9]*E[-+][0-9]+)") cnt := 0 while l := read() do every ReFind(pat, l) do { write(Re_ParenGroups[1], " is ", Re_ParenGroups[2]) cnt +:= 1 } write("cnt = ", cnt) end # main ma icont -u re.icn Translating: re.icn: main No errors Linking: ma ./re < dat XMULT is 1.11E-4 XMULT is 1.12E-4 XMULT is 1.13E-4 XMULT is 1.14E-4 XZERO is 4.21E-8 XZERO is 4.22E-8 XZERO is 4.23E-8 YMULT is 1.31E-6 YMULT is 1.32E-6 YMULT is 1.33E-6 YZERO is 0.41E+0 YZERO is 0.42E+0 YZERO is 0.43E+0 cnt = 13 ma The data came from the original posting; I modified it slightly to make it easier to see if everything was working correctly. What everyone is missing about procedures-that-do-the-job is the speed consideration. Well, o.k. - let's take a look. ma cat fi.icn procedure main() local numberchars, cnt, l numberchars := (&digits ++ 'e' ++ 'E' ++ '+' ++ '-' ++ '.') cnt := 0 while l := read() do l ? every tab(past("XMULT:"|"XZERO:"|"YMULT:"|"YZERO:", &subject)) do { write(tab(many(numberchars))) cnt +:= 1 } write("cnt = ", cnt) end # main procedure past(s1, s2, i1, i2) suspend find(s1, s2, i1, i2) + *s1 end ma icont -u fi.icn Translating: fi.icn: main past No errors Linking: ma ./fi < dat 1.11E-4 1.12E-4 1.13E-4 1.14E-4 4.21E-8 4.22E-8 4.23E-8 1.31E-6 1.32E-6 1.33E-6 0.41E+0 0.42E+0 0.43E+0 cnt = 13 ma i=0; while [ $i -lt 100 ]; do cat dat; i=`expr $i + 1`; done > dat.big ma wc -l dat dat.big 1 dat 100 dat.big 101 total ma time re < dat.big cnt = 1300 real 0m2.11s user 0m1.92s sys 0m0.03s ma time ./fi < dat.big cnt = 1300 real 0m0.28s user 0m0.13s sys 0m0.06s ma Re and fi were modified to avoid printing matched values. Regular expressions are an order of magnitude slower than the past generator on a sun ultra 2 with 168 mhz cpus and 128 meg of main store. I don't know what your situation is, but I'd be happy to pay the price in performance to get a more understandable (to me) parser (I realize this wasn't the dichotomy set up by the original poster). Think about embedding either procedure in a deep inner loop of some kind. Yeah, so? Either your parsing the same string over and over in a loop, in which case procedures aren't your problem, or you're parsing a new string every time, in which case what else are you going to do? From icon-group-sender Thu Dec 10 17:13:11 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id RAA07960 for icon-group-addresses; Thu, 10 Dec 1998 17:13:00 -0700 (MST) Message-Id: <199812110013.RAA07960@baskerville.CS.Arizona.EDU> Date: Thu, 10 Dec 1998 10:44:01 -0700 From: Gregg Townsend To: evans.nospam@gte.net, icon-group Subject: Re: Formatting Reals Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO I use the code below for formatting real numbers into fixed-width fields. It's not as general as C's printf, and it's interpreted, but it works. (And to answer another question: real numbers are implemented by C's "double" datatype.) --------------------------------------------------------------------------- Gregg Townsend Gould-Simpson Building gmt@cs.arizona.edu Staff Scientist 1040 E. 4th St. 32 13 45N 110 57 16W Dept. of Computer Science PO Box 210077 tel: +1 520 621 4325 The University of Arizona Tucson, AZ 85721-0077 fax: +1 520 621 4246 ============================================================================== procedure main() #: sample driver every write(frn(&pi, 20, 0 to 16)) end # frn(r, w, d) format real number r into a string with d digits # after the decimal point; a result narrower than w # characters is padded on the left with spaces. # Fixed format is always used; there is no exponential # notation. # # Defaults: w=0, d=0 $define MAXDECIMALS 25 procedure frn(r, w, d) #: format real number local s static mlist initial every put(mlist := list(), 10.0 ^ (0 to MAXDECIMALS)) r := real(r) | runerr(102, r) (/d := 0) | (d >:= MAXDECIMALS) if r >= 0.0 then { s := string(integer(r * mlist[d + 1] + 0.5)) s := right(s, *s < d + 1, "0") } else { s := string(integer(-r * mlist[d + 1] + 0.5)) s := right(s, *s < d + 1, "0") s := "-" || s } s := right(s, *s < (\w - 1)) return s ? (tab(-d) || "." || tab(0)) end From icon-group-sender Thu Dec 10 17:16:16 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id RAA08085 for icon-group-addresses; Thu, 10 Dec 1998 17:16:03 -0700 (MST) Message-Id: <199812110016.RAA08085@baskerville.CS.Arizona.EDU> Date: Thu, 10 Dec 1998 10:48:26 -0700 From: Gregg Townsend To: evans@gte.net, icon-group@optima.CS.Arizona.EDU Subject: Re: IPD261 Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO From: MJE How come IPD261 is not available here? http://www.eleves.ens.fr:8080/docs/icon/trs.html 261 deals with the superset of C in which Icon is written. You'd have to ask their webmaster, I guess. But it's available from the Icon web site in PostScript or PDF form. See http://www.cs.arizona.edu/icon/docs/docs.htm --------------------------------------------------------------------------- Gregg Townsend Gould-Simpson Building gmt@cs.arizona.edu Staff Scientist 1040 E. 4th St. 32 13 45N 110 57 16W Dept. of Computer Science PO Box 210077 tel: +1 520 621 4325 The University of Arizona Tucson, AZ 85721-0077 fax: +1 520 621 4246 From icon-group-sender Mon Dec 14 13:28:36 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id NAA00150 for icon-group-addresses; Mon, 14 Dec 1998 13:26:02 -0700 (MST) Message-Id: <199812142026.NAA00150@baskerville.CS.Arizona.EDU> To: icon-group@optima.CS.Arizona.EDU Date: Fri, 11 Dec 1998 19:40:48 -0500 From: "Robert L. Thornbury" Subject: Windows ICON Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO I have a question about ICON for Windows, version 9.3: When you write to standard output you get the console window. How is this control (size, scrolling, etc.) and is it possible to control this within the program you're writing. From icon-group-sender Mon Dec 14 13:31:21 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id NAA00338 for icon-group-addresses; Mon, 14 Dec 1998 13:31:14 -0700 (MST) Message-Id: <199812142031.NAA00338@baskerville.CS.Arizona.EDU> To: icon-group@optima.CS.Arizona.EDU Date: 12 Dec 1998 15:03:19 GMT From: espie@liafa.jussieu.fr (Marc Espie) Subject: Re: IPD261 Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO In article <199812110016.RAA08085@baskerville.CS.Arizona.EDU>, Gregg Townsend wrote: > From: MJE > > How come IPD261 is not available here? > http://www.eleves.ens.fr:8080/docs/icon/trs.html > 261 deals with the superset of C in which Icon is written. Probably because the mirroring broke at some point ? I haven't been too thorough in checking this... now that I'm no longer a student there, I'll think of adding a HUGE disclaimer that this mirror is old, provided only as a local convenience, AND currently discontinued. -- Marc Espie |anime, sf, juggling, unicycle, acrobatics, comics... |AmigaOS, OpenBSD, C++, perl, Icon, PostScript... | `real programmers don't die, they just get out of beta' From icon-group-sender Wed Dec 16 08:31:04 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA18826 for icon-group-addresses; Wed, 16 Dec 1998 08:29:37 -0700 (MST) Message-Id: <199812161529.IAA18826@baskerville.CS.Arizona.EDU> To: icon-group@optima.CS.Arizona.EDU Date: Wed, 16 Dec 1998 10:05:45 +0100 From: Anders Holtsberg Subject: Bug or feature????? Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Is this a raw bug or a feature? === 1 insert(allcolnames, 99999) every writes(!allcolnames, " ") write() gives > icont x2a Translating: x2a.icn: main splitontab No errors Linking: > cat barn.txt | x2a | grep G G1mf IgG4 99999 IgG1 IgG!+ IgG1+ Fenotyp G3mb+ Prov_nr IgG2+ Kön IgG3 IgG3+ G1mf+ IgG4+ G3mb+ ^^^^^ OK === 2 insert(allcolnames, 'abcde') every writes(!allcolnames, " ") write() gives > icont x2a Translating: x2a.icn: main splitontab No errors Linking: > cat barn.txt | x2a | grep G G1mf IgG4 abcde IgG1 IgG!+ IgG1+ Fenotyp G3mb+ Prov_nr IgG2+ Kön IgG3 IgG3+ G1mf+ IgG4+ G3mb+ ^^^^^ OK === 3 insert(allcolnames, "abcde") every writes(!allcolnames, " ") write() gives > icont x2a Translating: x2a.icn: main splitontab No errors Linking: > cat barn.txt | x2a | grep G G1mf IgG4 IgG1 IgG!+ IgG1+ Fenotyp G3mb+ Prov_nr IgG2+ Kön IgG3 IgG3+ G1mf+ IgG4+ G3mb+ ==================== WHAT? This must be a raw bug!? Where on earth did "abcde" go? To outer space?????? I'm must have this done NOW. I'm must deliver a consultant thing!!!!! AAAArrhhh!!!! Can anybody help me? I'm using Icon 9.3 on a Sun machine. -- Anders Holtsberg == Anders Holtsberg =========================== andersh@maths.lth.se == Department of Mathematical Statistics Phone +46 46 222 4953 Lund University Fax +46 46 222 4998 == Box 118, S-221 00 LUND, Sweden == http://www.maths.lth.se/matstat == From icon-group-sender Wed Dec 16 08:32:14 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA18962 for icon-group-addresses; Wed, 16 Dec 1998 08:32:07 -0700 (MST) Message-Id: <199812161532.IAA18962@baskerville.CS.Arizona.EDU> To: icon-group@optima.CS.Arizona.EDU Date: Wed, 16 Dec 1998 12:44:56 +0100 From: Anders Holtsberg Subject: Re: Bug or feature????? Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO I wrote: > > Is this a raw bug or a feature? Well, I discovered it. If you have elements consisting of the string "\r" you can end up with reeeeeeal strange things... I guess 9.3.1 solves the problem of getting spanked by embedded \r from Bill G :-) -- Andy == Anders Holtsberg =========================== andersh@maths.lth.se == Department of Mathematical Statistics Phone +46 46 222 4953 Lund University Fax +46 46 222 4998 == Box 118, S-221 00 LUND, Sweden == http://www.maths.lth.se/matstat == From icon-group-sender Wed Dec 16 17:43:02 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id RAA24402 for icon-group-addresses; Wed, 16 Dec 1998 17:42:41 -0700 (MST) Message-Id: <199812170042.RAA24402@baskerville.CS.Arizona.EDU> X-Authentication-Warning: helios.dmu.ac.uk: hgs owned process doing -bs Date: Wed, 16 Dec 1998 16:31:00 +0000 (GMT) From: Hugh Sasse To: icon-group@optima.CS.Arizona.EDU Subject: Icon Book in UK? Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Can anyone tell me of a stockist of "The Icon Programming Language" 3rd edition, in the UK, please? All the bookshops I have asked (in the East Midlands) say it will be about 3 weeks to obtain a copy, and amazon.co.uk say the same. Thank you. Hugh hgs@dmu.ac.uk From icon-group-sender Wed Dec 16 17:44:00 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id RAA24460 for icon-group-addresses; Wed, 16 Dec 1998 17:43:54 -0700 (MST) Message-Id: <199812170043.RAA24460@baskerville.CS.Arizona.EDU> X-Authentication-Warning: pluto.mscc.huji.ac.il: mslamm owned process doing -bs Date: Wed, 16 Dec 1998 19:47:18 +0200 (IST) From: Ehud Lamm To: icon-group@optima.CS.Arizona.EDU Subject: Icon Co-Expressions in Ada Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO I am thinking about implimenting Goal Directed Evaluation ala Icon, as an Ada package. I considred two options: 1. Using "static" data (that is, variables stored in the package's body, in Ada) to impliment the suspend mechanism. This has its obvious problems. 2. Using Ada's tasking facilites. This has the disadvantage of making the user use tasks. It is sad, since as far as I know you can't simply make an Ada procedure behave in a task like way, by invking other procedures. The task must be explicit. Any thoughts or ideas are more than welcome. If someone did it already - so much the better. I'd also be happy to see references (esp. Web based) on implimenting co-expressions. Thanks. Ehud Lamm mslamm@pluto.mscc.huji.ac.il From icon-group-sender Wed Dec 16 17:44:18 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id RAA24499 for icon-group-addresses; Wed, 16 Dec 1998 17:44:13 -0700 (MST) Message-Id: <199812170044.RAA24499@baskerville.CS.Arizona.EDU> Date: Wed, 16 Dec 1998 15:05:06 -0600 From: Clinton Jeffery To: thrnsoft@globalsite.net CC: icon-group@optima.CS.Arizona.EDU Subject: Re: Windows ICON Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO [Robert Thornbury wrote:] I have a question about ICON for Windows, version 9.3: When you write to standard output you get the console window. How is this control (size, scrolling, etc.) and is it possible to control this within the program you're writing. The "console" windows in the present implementation are pretty sad. They are, however, regular Icon "window" values in the sense that you should be able to manipulate their attributes the same as other windows open for graphics. This allows control of some features trivially, such as size, position, font used, etc. What everyone wants, though, is a scrollbar for this window, and that takes a little more work. The easiest way to do it is to overload the write()/writes() functions with library functions that store output to a list along with writing it to the console, and then install native Windows scrollbars and process their events to redraw the display from the list contents. I guess I should write this up as an example and add it to the documentation; you might try it and see for yourself, in the meantime. Clint Jeffery, jeffery@cs.utsa.edu Division of Computer Science, The University of Texas at San Antonio Research http://www.cs.utsa.edu/research/plss.html Will Hack For Food! From icon-group-sender Thu Dec 17 11:19:34 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id LAA14165 for icon-group-addresses; Thu, 17 Dec 1998 11:17:54 -0700 (MST) Message-Id: <199812171817.LAA14165@baskerville.CS.Arizona.EDU> Date: Wed, 16 Dec 1998 18:21:05 -0700 From: Ralph Griswold To: icon-group Subject: Small Icon programming problem Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Here's a small Icon programming problem for you to tackle: Write a procedure digsort(i) that returns the integer that results from sorting the digits of i, preserving sign. For example, digsort(201) should return 12 and digsort(-1042) should return -124. You may assume i is an integer. You could aim for brevity, speed, and/or clarity. Send solutions and comments to icon-group. The most interesting solutions will appear in a future issue of the Icon Analyst and sent to icon-group as a package. From icon-group-sender Thu Dec 17 11:20:28 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id LAA14260 for icon-group-addresses; Thu, 17 Dec 1998 11:20:22 -0700 (MST) Message-Id: <199812171820.LAA14260@baskerville.CS.Arizona.EDU> Date: Thu, 17 Dec 1998 09:31:14 -0600 From: MJE To: icon-group@optima.CS.Arizona.EDU Subject: COM on Unix Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Steve Wampler wrote: > > } I like your idea about an IPL pack. However, you have not incited me to > } commit an act of implementation. What interests me instead is making > } Icon parsing available in C language programs. > > } For that I will need to write a bunch of COM objects. That means > } "Component Object Model" for those not in the know, Microsoft's upgrade > } to the DLL concept. I have been mulling over this project for a while. > } A little more mulling, and I might be incited to commit an act of > } implementation. > > That will be interesting and certainly useful for those of you running > under Windows, but not much use to those of us who live in the non-MS > world. > COM is available for Unix. This article was from the start of the year: http://www.techweb.com/wire/story/TWB19980127S0015 COM is a good piece of design. Actually, the design was borrowed from public-domain ideas developed by a software foundation. Typical Micro$oft, but at least they bet on the right horses. Interested persons should get a copy of "Inside COM" from Microsoft Press. It's the primer for COM. -- Mark From icon-group-sender Thu Dec 17 12:31:35 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA17517 for icon-group-addresses; Thu, 17 Dec 1998 12:31:05 -0700 (MST) Message-Id: <199812171931.MAA17517@baskerville.CS.Arizona.EDU> Date: Thu, 17 Dec 1998 12:15:39 -0700 From: Ralph Griswold To: icon-group Subject: re: Small programming problem Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Duplicate digits should appear the correct number of times, as in 918171 -> 111789 From icon-group-sender Thu Dec 17 12:32:43 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA17561 for icon-group-addresses; Thu, 17 Dec 1998 12:32:26 -0700 (MST) Message-Id: <199812171932.MAA17561@baskerville.CS.Arizona.EDU> Date: Thu, 17 Dec 1998 11:07:13 -0800 From: kwalker@sfo.harbinger.com (Ken Walker) To: icon-group@optima.CS.Arizona.EDU Subject: Re: Small Icon programming problem Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Here is a rather straightforward solution to the problem of sorting digits while preserving the sign of an integer. There should be a solution that is shorter and more obscure; I thought of trying csets, but they discard duplicate digits... Ken Walker, kenneth.walker@sfo.harbinger.com Harbinger Coporation, Concord, Ca. 94520 procedure disort(i) local digitLst, sortedInt; # # Separate the integer into a sign and a list of digits. # digitLst := []; i ? { sortedInt := tab(any('-+')) | "" while put(digitLst, move(1)); } # # Sort the digits and append them to the output. # digitLst := sort(digitLst); while sortedInt ||:= get(digitLst); return integer(sortedInt); end (You can tell I've been programming too much in C by all the semicolons at the end of lines; it also took me a few tries to get all the colons before the equals. :-) From icon-group-sender Thu Dec 17 16:30:18 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA26123 for icon-group-addresses; Thu, 17 Dec 1998 16:29:53 -0700 (MST) Message-Id: <199812172329.QAA26123@baskerville.CS.Arizona.EDU> From: Norman Ramsey Date: Thu, 17 Dec 1998 14:45:06 -0500 To: icon-group@optima.CS.Arizona.EDU Subject: Ralph's Small Icon programming problem Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Very small indeed: procedure digsort(n) return integer(cset(n)) end From icon-group-sender Thu Dec 17 16:31:12 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA26207 for icon-group-addresses; Thu, 17 Dec 1998 16:31:06 -0700 (MST) Message-Id: <199812172331.QAA26207@baskerville.CS.Arizona.EDU> From: gep2@computek.net Date: Thu, 17 Dec 1998 14:03:02 -0600 (CST) Subject: Re: Small Icon programming problem To: icon-group@optima.CS.Arizona.EDU Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO > Here is a rather straightforward solution to the problem of sorting digits while preserving the sign of an integer. Here's another, in SNOBOL4 this time (assuming running under SPITBOL, or that FULLSCAN is turned on): DEFINE("DISORT(DISORT)I,J") DD = "0123456789" :(DISORT_END) DISORT DISORT ANY(DD) $ I ANY(DD) $ J *GT(I,J) = J I :S(DISORT)F(RETURN) DISORT_END Gordon Peterson http://www.computek.net/public/gep2/ Support the Anti-SPAM Amendment! Join at http://www.cauce.org/ From icon-group-sender Thu Dec 17 16:31:35 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA26236 for icon-group-addresses; Thu, 17 Dec 1998 16:31:29 -0700 (MST) Message-Id: <199812172331.QAA26236@baskerville.CS.Arizona.EDU> Date: Thu, 17 Dec 1998 13:36:27 -0700 From: Steve Wampler X-Accept-Language: en To: icon-group@optima.CS.Arizona.EDU Subject: Re: Small Icon programming problem Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Ralph Griswold wrote: > > Here's a small Icon programming problem for you to tackle: > > Write a procedure digsort(i) that returns the integer that > results from sorting the digits of i, preserving sign. For > example, digsort(201) should return 12 and digsort(-1042) > should return -124. You may assume i is an integer. > > You could aim for brevity, speed, and/or clarity. > > Send solutions and comments to icon-group. The most interesting > solutions will appear in a future issue of the Icon Analyst and > sent to icon-group as a package. Well, here's one that is short and obscure. I have another, similar one that avoids the int->string and string->int conversions, but it runs ~20% slower than this one. procedure digsort(i) local a,s every put(a := [], !i) # separate the digits and sign every (s := "", s ||:= !sort(a)) # sort and rejoin (string conversion) return integer(s) # convert back to integer end -- Steve Wampler (swampler@gemini.edu) From icon-group-sender Thu Dec 17 16:31:54 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA26266 for icon-group-addresses; Thu, 17 Dec 1998 16:31:48 -0700 (MST) Message-Id: <199812172331.QAA26266@baskerville.CS.Arizona.EDU> Date: Thu, 17 Dec 1998 14:21:23 -0700 From: Steve Wampler X-Accept-Language: en To: icon-group@optima.CS.Arizona.EDU Subject: Re: Small Icon programming problem Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Ralph Griswold wrote: > > Here's a small Icon programming problem for you to tackle: > > Write a procedure digsort(i) that returns the integer that > results from sorting the digits of i, preserving sign. For > example, digsort(201) should return 12 and digsort(-1042) > should return -124. You may assume i is an integer. > > You could aim for brevity, speed, and/or clarity. > > Send solutions and comments to icon-group. The most interesting > solutions will appear in a future issue of the Icon Analyst and > sent to icon-group as a package. What a fun thing to play with! Here's two more solutions. For my test cases these are the fastest I've been able to come up with. (I suspect there is a much faster approach involving map(), but this may just be a pipedream.) The 2nd is slightly faster, but relies on the trick of returning a string that looks right (so it's hard to tell that it isn't returning an integer.) Performance is affected by the choice of input. procedure digsort(i) local s, c s := "" i := string(i) # convert to string every c := !cset(i) do { # get correct order every s ||:= (find(c,i) & c) # get correct count } return integer(s) # convert back to int end The next version is barely faster, due to a 'trick' and has an obscure bit of code in cset(integer(cset(i))): procedure digsort(i) local s, c, j s := "" i := string(i) # convert to string every c := !cset(integer(cset(i))) do { # get correct order & toss 0 every s ||:= (find(c,i) & c) # get correct count } return s end -- Steve Wampler (swampler@gemini.edu) From icon-group-sender Thu Dec 17 16:32:13 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA26292 for icon-group-addresses; Thu, 17 Dec 1998 16:32:06 -0700 (MST) Message-Id: <199812172332.QAA26292@baskerville.CS.Arizona.EDU> Date: Thu, 17 Dec 1998 16:23:50 -0600 From: MJE To: icon-group@baskerville.CS.Arizona.EDU Subject: [Fwd: Re: Icon] Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO This is a multi-part message in MIME format. --------------73692FF93855 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Anyone got an answer for this chap? -- Mark --------------73692FF93855 Content-Type: message/rfc822 Content-Disposition: inline Received: from cairo.purplefrog.com ([209.40.32.49]) by mta1.mailsrvcs.net (InterMail v03.02.04 118 119) with ESMTP id <19981217171549.IFCG14453@cairo.purplefrog.com> for ; Thu, 17 Dec 1998 11:15:49 -0600 Received: from cairo.purplefrog.com (localhost [127.0.0.1]) by cairo.purplefrog.com (8.8.5/8.8.5) with ESMTP id MAA25902 for ; Thu, 17 Dec 1998 12:13:38 -0500 Message-Id: <199812171713.MAA25902@cairo.purplefrog.com> From: thoth@purplefrog.com To: evans@gte.net Subject: Re: Icon In-reply-to: Your message of "Thu, 17 Dec 1998 09:00:56 CST." <36791CA8.301@gte.net> Date: Thu, 17 Dec 1998 12:13:38 -0500 Sender: thoth@cairo.purplefrog.com MIME-Version: 1.0 MJE ,in message <36791CA8.301@gte.net>, wrote: > Icon -- better than perl! Links below. I couldn't find the regular expression operators... Although, for sheer number of operators, Icon is competing with J and APL. -- Bob Forsman thoth@gainesville.fl.us http://www.gainesville.fl.us/~thoth/ --------------73692FF93855-- From icon-group-sender Thu Dec 17 16:32:31 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA26327 for icon-group-addresses; Thu, 17 Dec 1998 16:32:25 -0700 (MST) Message-Id: <199812172332.QAA26327@baskerville.CS.Arizona.EDU> Date: Thu, 17 Dec 1998 14:43:06 -0800 From: kwalker@sfo.harbinger.com (Ken Walker) To: icon-group@optima.CS.Arizona.EDU Subject: Re: Small Icon programming problem Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Okay, here is a slighty more obscure solution to the digit sorting problem (the lack of comments helps make it seem even more obscure than it is). Ken Walker, kenneth.walker@sfo.harbinger.com Harbinger Coporation, Concord, Ca. 94520 procedure disort(i) local sortedInt, c sortedInt := "" every c := !"-123456789" do i ? while sortedInt ||:= (tab(upto(c)), tab(many(c))) return integer(sortedInt) end From icon-group-sender Thu Dec 17 16:33:02 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id QAA26376 for icon-group-addresses; Thu, 17 Dec 1998 16:32:56 -0700 (MST) Message-Id: <199812172332.QAA26376@baskerville.CS.Arizona.EDU> From: "Nevin Liber" To: Subject: digisort Date: Thu, 17 Dec 1998 17:18:15 -0600 X-Priority: 3 (Normal) X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Ken Walker wrote: > Here is a rather straightforward solution to the problem of > sorting digits while preserving the sign of an integer. Since ASCII "-" comes before "0" in sort order, there is no need to special case the minus sign. Here is a smaller straightforward (IMHO) solution, which is the same in principle as Ken's, yet differs very widely in the details: procedure digisort(i) local L local s L := list() every put(L, !i) s := "" every s ||:= !sort(L) return integer(s) end 1. I tend to use the idiom L := list() instead of L := []. 2. Ken used string scanning to build the list, while I used element generation. 3. Ken used the destructive (to a list L1) get(L1) to build the string, while I used the non-destructive element generation !L1. > I thought of trying csets, but they discard duplicate digits... digisort() really consists of two subproblems: counting and sorting. If you seperate out the counting, you can use cset() to do the sorting, as in: procedure digisort(i) local T local s T := table("") every s := !i do T[s] ||:= s s := "" every s ||:= T[!cset(i)] return integer(s) end T is a table with each digit as a key whose value is a string of that digit with a length corresponding to the number of times that digit appears in i, and cset(i) does the sorting. If you wanted to make the counting more explicit, you could do something like: procedure digisort(i) local T local s1 local s2 T := table(0) every T[!i] +:= 1 s1 := "" every s2 := !cset(i) do s1||:= repl(s2, T[s2]) return integer(s1) end If you didn't want to build up a list or a table, you could do the sorting first and then the counting by multiple passes over (the string of) i, as in: procedure digisort(i) local s local s1 local s2 s := string(i) s2 := "" every s1 := !cset(s) do s ? { while tab(find(s1)) do { s2 ||:= move(1) } } return integer(s2) end > There should be a solution that is shorter and more obscure; Here you go :-): procedure digisort(i) local s s := "" every s ||:= (i ? (tab(find(!cset(&subject))) & move(1))) return integer(s) end You can even replace cset(&subject) with cset(i) to make it ever-so-slightly shorter, but I think that taking the cset of a string is ever-so-slightly faster than taking the cset of an integer. Of course, one could find parallels between the internal way that cset(s) converts a string to a cset (I'm guessing by a bucket sort) and the digisort() algorithm itself... > (You can tell I've been programming too much in C by all the > semicolons at the end of lines; it also took me a few tries > to get all the colons before the equals. :-) (And I've been programming too much in MUMPS lately, which is why all my variables are only one or two letters long. :-)) __ Nevin ":-)" Liber (312) 855-1000 x199 National Systems Corporation 414 North Orleans Street, Suite 501 Chicago, IL 60610-4490 fax: (312) 222-1605 From icon-group-sender Fri Dec 18 08:13:57 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA08021 for icon-group-addresses; Fri, 18 Dec 1998 08:12:56 -0700 (MST) Message-Id: <199812181512.IAA08021@baskerville.CS.Arizona.EDU> Date: Thu, 17 Dec 1998 16:52:36 -0700 From: Ralph Griswold To: icon-group Subject: Early issues of the Icon Analyst Now On-Line Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO We've put the first six issues of the Icon Analyst on-line in PDF format. See the link near the top of the Icon home page. We will add other early issues from time to time, but recent years will not be made available on-line.  From icon-group-sender Fri Dec 18 08:16:09 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA08136 for icon-group-addresses; Fri, 18 Dec 1998 08:15:54 -0700 (MST) Message-Id: <199812181515.IAA08136@baskerville.CS.Arizona.EDU> To: icon-group@optima.CS.Arizona.EDU Date: Thu, 17 Dec 1998 20:45:05 -0700 From: Cheyenne Wills Subject: Re: Small Icon programming problem Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Well... here is my humble solution... procedure main(a) v := integer(a[1]) | stop("Invalid input...") t := table("") o := "" every c := !v do \t[c] ||:= c every c := !"-0123456789" do o ||:= t[c] write(integer(o)) end Cheyenne Wills From icon-group-sender Fri Dec 18 08:18:20 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA08236 for icon-group-addresses; Fri, 18 Dec 1998 08:18:13 -0700 (MST) Message-Id: <199812181518.IAA08236@baskerville.CS.Arizona.EDU> To: icon-group@optima.CS.Arizona.EDU Date: Thu, 17 Dec 1998 20:48:53 -0700 From: Cheyenne Wills Subject: Re: Small Icon programming problem Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Woops... you wanted a procedure... my modified humble submission... procedure digsort(v) # Assumes v is a valid integer t := table("") o := "" every c := !v do \t[c] ||:= c every c := !"-0123456789" do o ||:= t[c] return integer(o) end Cheyenne Wills From icon-group-sender Mon Dec 21 09:34:41 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id JAA04012 for icon-group-addresses; Mon, 21 Dec 1998 09:32:44 -0700 (MST) Message-Id: <199812211632.JAA04012@baskerville.CS.Arizona.EDU> Date: Sat, 19 Dec 1998 18:27:20 -0700 From: Ralph Griswold To: icon-group Subject: University Holiday Closing Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO The University of Arizona will be closed from December 24, 1998 through January 3, 1999. During that period, electronic mail and our Web and FTP sites should be available as normal, although if there are problems, it may take longer than usual to fix them. There will, however, be no office staff on duty to receive telephone calls, faxes, letters, or electronic mail. From icon-group-sender Mon Dec 21 09:39:52 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id JAA04197 for icon-group-addresses; Mon, 21 Dec 1998 09:39:46 -0700 (MST) Message-Id: <199812211639.JAA04197@baskerville.CS.Arizona.EDU> To: icon-group@optima.CS.Arizona.EDU Date: Sun, 20 Dec 1998 01:02:51 GMT From: static@operamail.com.au (Wade Bowmer) Subject: Re: Small Icon programming problem Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO On 17 Dec 1998 13:21:34 -0500, Ralph Griswold wrote: > Here's a small Icon programming problem for you to tackle: > > Write a procedure digsort(i) that returns the integer that > results from sorting the digits of i, preserving sign. For > example, digsort(201) should return 12 and digsort(-1042) > should return -124. You may assume i is an integer. > > You could aim for brevity, speed, and/or clarity. I dunno what to aim for. However, trying it out raises a question: what is digsort(737) supposed to produce? 377 or 37? My solution outputs the former. procedure digsort(in) s := string(in) | return fail t := table(0) every t[!s] +:= 1 s := "" every i := !sort(t,1) do s ||:= repl(i[1], i[2]) return integer(s) end Wade. From icon-group-sender Mon Dec 21 09:41:14 1998 Return-Path: Received: (from root@localhost) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id JAA04295 for icon-group-addresses; Mon, 21 Dec 1998 09:41:07 -0700 (MST) Message-Id: <199812211641.JAA04295@baskerville.CS.Arizona.EDU> To: icon-group@optima.CS.Arizona.EDU Date: 21 Dec 1998 04:36:42 -0600 From: msglass@MCS.COM (Michael Glass) Subject: Re: Small Icon programming problem Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO This won't win any brevity or obscurity awards, but it is another approach. procedure digsort(i) return if i < 0 then -digsort1(-i) else digsort1(i) end procedure digsort1(i) local pt1, pt2 if i[pt1 := 2 to *i] < i[pt2 := 1 to pt1-1] then return digsort1(i - (i[pt2] - i[pt1]) * (10^(pt1 - pt2) - 1) * 10^(*i - pt1)) return i end -- Michael Glass Illinois Institute of Technology (engaging in major work-avoidance) From icon-group-sender Fri Dec 25 18:21:28 1998 Return-Path: Received: from ursus.CS.Arizona.EDU (ursus.CS.Arizona.EDU [192.12.69.63]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id SAA20391 for ; Fri, 25 Dec 1998 18:21:27 -0700 (MST) Received: by ursus.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA01644; Fri, 25 Dec 1998 18:21:26 -0700 Date: Thu, 24 Dec 1998 05:16:02 -0600 Message-Id: <199812241116.FAA01376@segfault.cs.utsa.edu> From: Clinton Jeffery To: icon-group@optima.CS.Arizona.EDU Cc: davidr1@express-news.net Subject: Merry Christmas to all Reply-To: jeffery@cs.utsa.edu Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO In the spirit of our own Chris Tenaglia, who has contributed more games to the Icon community than anyone else, especially on holidays, I would like to present you with a fine version of the classic game of Tetris. It was written by high school senior David Rice, and will be featured in our forthcoming book, Programming with Icon. It runs unmodified on UNIX and Windows Icon, requires graphics facilities, is only a few hundred lines long, and has a nice feature set. If you enhance it further, David and I would love to get copies of your improvements. I can personally vouch that it is highly playable, but if you find any bugs or have any problems with it, we would like to know about that too. Cheers! Clint Jeffery, jeffery@cs.utsa.edu Division of Computer Science, The University of Texas at San Antonio Research http://www.cs.utsa.edu/research/plss.html Will Hack For Food! ############################################################################ # # File: iTetris.icn # # Subject: An Icon version of the classic game Tetris # # Author: David Rice # # Date: December 10, 1998 # ############################################################################ # # Version: 2.0 # ############################################################################ # # This file is in the public domain. # ############################################################################ # # This program generates random pieces that fall from the top # of the screen. The object is to position the pieces in a way # that they complete a horizontal row. Scoring is done by 50 # points for one row, 100 for two, 200 for three, and 400 # points for a tetris, or four rows. Another five points are # awarded for every piece played. Levels increase every time # that ten rows are deleted. # ############################################################################ # # Requires: Version 9 graphics # ############################################################################ # # Links: graphics, random # ############################################################################ link graphics link random $include "keysyms.icn" global activecells, activecellcolor, nextpiece, nextcolor, L, colors, score, numrows, level, delaytime, pieceposition, button_status, game_status procedure main() repeat { game_status := 0 init() text1 := ["Start", "green", 45, 285] text2 := ["Pause", "red", 40, 285] button_status := 0 repeat if buttons(15, 105, 270, 290, text1, text2) == "done" then break every cell := !nextpiece do drawcell(-40 + (cell[2]-1)*15, 60 + (cell[1]-1)*15, nextcolor) every cell := !activecells do if cell ~=== colors["black"] then drawcell(120 + (cell[2]-1)*15, 481, activecellcolor) game_status := 1 game_loop() } end procedure init() randomize() if /&window then { &window := open("iTetris","g","size=276,510", "posx=20", "bg=black") } WAttrib("fg=white", "bg=black", "font=sans,bold,15") EraseArea(0, 0, 276, 510) DrawString(15,50,"Next Object") WAttrib("bg=vivid blue", "font=serif,italic,bold,16") GotoXY(4,16) WWrites(" ITETRIS 2.0 ") WAttrib("fg=dark weak greenish cyan", "linewidth=1", "font=sans,bold,16") DrawRectangle(15, 270, 90, 20, 15, 300, 90, 20, 15, 330, 90, 20, 15, 360, 90, 20) Fg("green") DrawString(45, 285, "Start") Fg("pale vivid red-yellow") DrawString(26, 315, "New Game", 47, 345, "Quit", 41, 375, "About") WAttrib("fg=white", "font=serif,italic,bold,16") DrawString(12, 150, "Score: " || "0", 12, 170, "Rows: " || "0", 12, 200, "LEVEL: " || "0") Fg("dark vivid gray") FillRectangle(119,19,152,451, 119,479,152,17) WAttrib("fg=pale vivid red-yellow", "bg=dark vivid gray") DrawRectangle(119,19,151,451, 119,480,151,16) numrows := score := level := 0 delaytime := 200 colors := table(&window) every c := ("blue"|"yellow"|"cyan"|"green"|"red"|"white"| "red-yellow" | "purple-magenta") do colors[c] := Clone("fg=" || c) colors["black"] := Clone(&window, "fg=dark vivid gray") L := list(30) every !L := list(10, colors["black"]) newobject() activecells := copy(nextpiece) activecellcolor := copy(nextcolor) every point := !activecells do L[point[1], point[2]] := colors[activecellcolor] newobject() end procedure game_loop() repeat { while *Pending() > 0 do { case Event() of { Key_Left : move_piece(-1, 0) Key_Right : move_piece(1, 0) Key_Down : move_piece(0, 1) Key_Up : rotate_piece() " " : drop() &lpress : { if 15 <= &x <= 105 then { if 270 <= &y <= 290 then pause() else if 300 <= &y <= 320 then return else if 360 <= &y <= 380 then about_itetris() } } &lrelease : if ((15 <= &x <= 105) & (330 <= &y <= 350)) then exit() } } every point1 := !activecells do { if point1[1] + 1 = (point2 := !activecells)[1] & point1[2] = point2[2] then { } else if (point1[1] = 30) | (L[point1[1] + 1, point1[2]] ~=== colors["black"]) then { if point2[1] = 3 then { EraseArea(120,481,150,15) Bg("black") every cell := !nextpiece do EraseArea(-40 + (cell[2]-1)*15, 60 + (cell[1]-1)*15, 15, 15) every (x := 30 to 1 by -1, y := 1 to 10) do { temp := ?["red-yellow", "yellow", "blue", "cyan", "red", "green", "purple-magenta"] Fg(temp) drawcell(120 + (y-1)*15, 20 + (x-1)*15, temp) WDelay(1) } every (x := 1 to 30, y := 1 to 10) do { FillRectangle(colors["black"], 120 + (y-1)*15, 20 + (x-1)*15, 15, 15) WDelay(1) } Notice("Game Over") return } while get(Pending()) scanrows() Fg("black") DrawString(12, 150, "Score: " || score) score +:= 5 Fg("white") DrawString(12, 150, "Score: " || score) activecells := copy(nextpiece) activecellcolor := copy(nextcolor) every point := !activecells do L[point[1], point[2]] := colors[activecellcolor] newobject() EraseArea(120,481,150,15) Bg("black") every cell := !activecells do { EraseArea(-40 + (cell[2]-1)*15, 60 + (cell[1]-1)*15, 15, 15) if cell ~=== colors["black"] then drawcell(120 + (cell[2]-1)*15, 481, activecellcolor) } every cell := !nextpiece do drawcell(-40 + (cell[2]-1)*15, 60 + (cell[1]-1)*15, nextcolor) break } } newactivecells := [] Bg("dark vivid gray") every cell := !activecells do { put(newactivecells, copy(cell)) newactivecells[-1, 1] +:= 1 EraseArea(120 + (cell[2]-1)*15, 20 + (cell[1]-1)*15, 15, 15) L[cell[1], cell[2]] := colors["black"] } every cell := !newactivecells do { L[cell[1], cell[2]] := colors[activecellcolor] drawcell(120 + (cell[2]-1)*15, 20 + (cell[1]-1)*15, activecellcolor) } WSync() activecells := newactivecells delay(delaytime) } end procedure newobject() case nextcolor := ?["red-yellow", "red", "yellow", "green", "cyan", "blue", "purple-magenta"] of { "red-yellow": { nextpiece := [ [1,5], [1,6], [2,5], [2,6] ] } "red": { nextpiece := [ [3,6], [1,6], [2,6], [4,6] ] pieceposition := 1 } "yellow": { nextpiece := [ [2,6], [1,6], [2,5], [2,7] ] } "green": { nextpiece := [ [2,6], [1,5], [1,6], [2,7] ] pieceposition := 1 } "cyan": { nextpiece := [ [2,6], [1,6], [1,7], [2,5] ] pieceposition := 1 } "blue": { nextpiece := [ [2,6], [1,5], [2,5], [2,7] ] } "purple-magenta": { nextpiece := [ [2,6], [1,7], [2,5], [2,7] ] } } end procedure move_piece(x, y) every point := !activecells do { # point wants to move to [point[1], point[2] + 1] if ((point[2] + x) < 1) | ((point[2] + x) > 10) then fail if point[1] + y > 30 then fail if L[point[1] + y, point[2] + x] === colors["black"] then next every point2 := !activecells do if (point[1] + y = point2[1]) & point[2] + x = point2[2] then break next if L[point[1] + y, point[2] + x] ~=== colors["black"] then fail } newactivecells := [] every cell := !activecells do { put(newactivecells, copy(cell)) newactivecells[-1, 2] +:= x newactivecells[-1, 1] +:= y EraseArea(120 + (cell[2]-1)*15, 20 + (cell[1]-1)*15, 15 , 15) L[cell[1], cell[2]] := colors["black"] } EraseArea(120,481,150,15) every cell := !newactivecells do { L[cell[1], cell[2]] := colors[activecellcolor] drawcell(120 + (cell[2]-1)*15, 20 + (cell[1]-1)*15, activecellcolor) if cell ~=== colors["black"] then drawcell(120 + (cell[2]-1)*15, 481, activecellcolor) } WSync() activecells := newactivecells end procedure drop() repeat { every point1 := !activecells do { if point1[1] + 1 = (point2 := !activecells)[1] & point1[2] = point2[2] then { } else if (point1[1] = 30) | (L[point1[1] + 1, point1[2]] ~=== colors["black"]) then { while get(Pending()) return } } newactivecells := [] every cell := !activecells do { put(newactivecells, copy(cell)) newactivecells[-1, 1] +:= 1 EraseArea(120 + (cell[2]-1)*15, 20 + (cell[1]-1)*15, 15 , 15) L[cell[1], cell[2]] := colors["black"] } every cell := !newactivecells do { L[cell[1], cell[2]] := colors[activecellcolor] drawcell(120 + (cell[2]-1)*15, 20 + (cell[1]-1)*15, activecellcolor) } WSync() activecells := newactivecells } end procedure rotate_piece() if activecellcolor === "red-yellow" then fail newactivecells := list() centerpoint := copy(activecells[1]) differencelist := list() every point := ! activecells do { temp := [ centerpoint[1] - point[1], centerpoint[2] - point[2] ] put(differencelist, temp) next } every cell := !activecells do put(newactivecells, copy(cell)) if activecellcolor === ("red" | "green" | "cyan") & (pieceposition = 2) then { every foo := 1 to *newactivecells do { newactivecells[foo,1] := centerpoint[1] + differencelist[foo,2] newactivecells[foo,2] := centerpoint[2] + differencelist[foo,1] * -1 pieceposition := 1 } } else { every foo := 1 to *newactivecells do { newactivecells[foo, 1] := centerpoint[1] + differencelist[foo,2] * -1 newactivecells[foo, 2] := centerpoint[2] + differencelist[foo,1] if activecellcolor === ("red" | "green" | "cyan") & (pieceposition = 1) then pieceposition := 2 } } every foo := 1 to *newactivecells do { if not ((1 <= newactivecells[foo, 1] <= 30) & (1 <= newactivecells[foo, 2] <= 10)) then fail if L[newactivecells[foo, 1], newactivecells[foo, 2]] === colors["black"] then next every point2 := !activecells do { if (newactivecells[foo, 1] = point2[1]) & newactivecells[foo, 2] = point2[2] then break next } if L[newactivecells[foo, 1], newactivecells[foo, 2]] ~=== colors["black"] then fail } every cell := !activecells do { EraseArea(120 + (cell[2]-1)*15, 20 + (cell[1]-1)*15, 15 , 15) L[cell[1], cell[2]] := colors["black"] } EraseArea(120,481,150,15) every cell := !newactivecells do { L[cell[1], cell[2]] := colors[activecellcolor] drawcell(120 + (cell[2]-1)*15, 20 + (cell[1]-1)*15, activecellcolor) if cell ~=== colors["black"] then drawcell(120 + (cell[2]-1)*15, 481, activecellcolor) } WSync() activecells := newactivecells end procedure scanrows() scanned_rows := table() rows_to_delete := [] every point := !activecells do { if \scanned_rows[point[1]] then next scanned_rows[point[1]] := 1 every (x := 1 to 10) do { if L[point[1], x] === colors["black"] then { break next } else next } put(rows_to_delete, point[1]) } if *rows_to_delete > 0 then { Fg("black") DrawString(12, 150, "Score: " || score, 12, 170, "Rows: " || numrows, 12, 200, "LEVEL: " || level) numrows +:= *rows_to_delete level := integer(numrows / 10) score +:= 50 * (2 ^ (*rows_to_delete - 1)) delaytime := 200 - (10 * level) Fg("white") DrawString(12, 150, "Score: " || score, 12, 170, "Rows: " || numrows, 12, 200, "LEVEL: " || level) deleterows(rows_to_delete) } end procedure deleterows(rows_to_delete) temp := [] current_row := 30 rows_to_delete := sort(rows_to_delete) row_set := set() every insert(row_set, !rows_to_delete) while current_row >= rows_to_delete[1] do { push(temp, pull(L)) current_row -:= 1 } temp_size := *temp current_row := 1 basesize := *L while *temp>0 do { if member(row_set, basesize + current_row) then { push(L, list(10, colors["black"])) pop(temp) } else put(L, pop(temp)) current_row +:= 1 } every (x := 1 to 30, y := 1 to 10) do { FillRectangle(L[x, y], 120 + (y-1)*15, 20 + (x-1)*15, 15, 15) if L[x,y] ~=== colors["black"] then DrawRectangle(colors["white"], 120 + (y-1)*15, 20 + (x-1) * 15, 14, 14) } WSync() end procedure pause() text1 := ["Start", "green", 45, 285] text2 := ["Pause", "red", 40, 285] button_status := 0 game_status := 0 Bg("black") EraseArea(16, 271, 89, 19) Font("sans,bold,16") Fg("green") DrawString(45, 285, "Start") FillRectangle(colors["black"], 120,20,150,450, 120,481,150,15) every cell := !nextpiece do EraseArea(-40 + (cell[2]-1)*15, 60 + (cell[1]-1)*15, 15, 15) repeat { Fg("white") Font("sans,italic,bold,20") CenterString(195, 234, "-PAUSED-") if (buttons(15, 105, 270, 290, text1, text2)) == "done" then break } refresh_screen() game_status := 1 end procedure buttons(x1, x2, y1, y2, text1, text2) while *Pending() > 0 do { case Event() of { &lpress : { if (15 <= &x <= 105) & (330 <= &y <= 350) then exit() if x1 <= &x <= x2 then if y1 <= &y <= y2 then { Bg(text1[2]) EraseArea(x1 + 1, y1 + 1, 89, 19) Font("sans,bold,16") Fg("black") DrawString(text1[3], text1[4], text1[1]) button_status := 1 } else if (360 <= &y <= 380) then about_itetris() else if (300 <= &y <= 320) then main() else button_status := 0 } &ldrag : { if not ((x1 <= &x <= x2) & (y1 <= &y <= y2)) then button_status := 0 } &lrelease: { if ((x1 <= &x <= x2) & (y1 <= &y <= y2) & (button_status = 1)) then { Bg("black") EraseArea(x1 - 2, y1 - 2, 95, 25) WAttrib("fg=dark weak greenish cyan", "linewidth=1") DrawRectangle(x1, y1, 90, 20) Font("sans,bold,16") Fg(text2[2]) DrawString(text2[3], text2[4], text2[1]) Font("serif,italic,bold,16") return "done" } return "keep goin" } } px := WAttrib("pointerx") py := WAttrib("pointery") if not ((x1 <= &x <= x2) & (y1 <= &y <= y2)) then { Bg("black") EraseArea(x1 - 2, y1 - 2, 95, 25) WAttrib("fg=dark weak greenish cyan", "linewidth=1") DrawRectangle(x1, y1, 90, 20) WAttrib("font=sans,bold,16", "fg=" || text1[2]) DrawString(text1[3], text1[4], text1[1]) } } end procedure about_itetris() about := WOpen("label=About iTetris", "size=300,200", "bg=black", "fg=white", "posx=10", "posy=155") | fail every cell := !nextpiece do EraseArea(-40 + (cell[2]-1)*15, 60 + (cell[1]-1)*15, 15, 15) FillRectangle(colors["black"], 120,20,150,450, 120,481,150,15) CenterString(about, 150, 25, "Written By: David Rice") CenterString(about, 150, 50, "Communications Arts HS, San Antonio") CenterString(about, 150, 90, "with technical assistance from") CenterString(about, 150, 115, "Clinton Jeffery") CenterString(about, 150, 180, "Christmas 1998") repeat { case Event(about) of { "\e" | "Q" | "q" : break &lpress : break } } while get(Pending()) WClose(about) if game_status = 1 then refresh_screen() end procedure refresh_screen() Bg("dark vivid gray") every cell := !nextpiece do drawcell(-40 + (cell[2]-1)*15, 60 + (cell[1]-1)*15, nextcolor) every cell := !activecells do { if cell ~=== colors["black"] then drawcell(120 + (cell[2]-1)*15, 481, activecellcolor) } every (x := 1 to 30, y := 1 to 10) do { FillRectangle(L[x, y], 120 + (y-1)*15, 20 + (x-1)*15, 15, 15) if L[x,y] ~=== colors["black"] then DrawRectangle(colors["white"], 120 + (y-1)*15, 20 + (x-1) * 15, 14, 14) } end procedure drawcell(x,y,color) FillRectangle(colors[color],x,y,15,15) DrawRectangle(colors["white"], x, y, 14, 14) end From icon-group-sender Mon Dec 28 07:18:41 1998 Return-Path: Received: from ursus.CS.Arizona.EDU (ursus.CS.Arizona.EDU [192.12.69.63]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id HAA22743 for ; Mon, 28 Dec 1998 07:18:40 -0700 (MST) Received: by ursus.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA06246; Mon, 28 Dec 1998 07:18:40 -0700 Message-Id: <3686763A.6CCC@gte.net> Date: Sun, 27 Dec 1998 12:02:34 -0600 From: MJE Reply-To: evans@gte.net Organization: None X-Mailer: Mozilla 3.01 (Win95; I) Mime-Version: 1.0 To: icon-group@optima.CS.Arizona.EDU Subject: EditPAD References: <199812241116.FAA01376@segfault.cs.utsa.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Errors-To: icon-group-errors@optima.CS.Arizona.EDU Content-Transfer-Encoding: 7bit Status: RO Windows users might be interested in EditPAD, http://www.ping.be/jg/ This thing is free and it's the best notepad replacement in the world. Takes up no disk space at all, does everything you want in a simple text editor. Perfect for editing Icon source code. Mark Evans From icon-group-sender Wed Dec 30 13:54:31 1998 Return-Path: Received: from ursus.CS.Arizona.EDU (ursus.CS.Arizona.EDU [192.12.69.63]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id NAA09557 for ; Wed, 30 Dec 1998 13:54:30 -0700 (MST) Received: by ursus.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM) id AA10752; Wed, 30 Dec 1998 13:54:30 -0700 X-Lotus-Fromdomain: JOHNSON_CONTROLS From: "Tenaglia, Chris D" To: icon-group@optima.CS.Arizona.EDU Message-Id: <852566E9.007763B8.00@Corpnotes.JCI.Com> Date: Tue, 29 Dec 1998 16:42:10 -0600 Subject: Happy Holidays Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Errors-To: icon-group-errors@optima.CS.Arizona.EDU Status: RO Seasons Greetings from the Tenaglia's at http://www.execpc.com/~cdt/merry.html note 1 : editpad is a nice editor. i wish it had 'autoindent' note 2 : I miss writing icon games. The computers I have access to now seem less friendly to icon. (VMS and HPux). note 3: I think icon is an ideal internet programming language in the CGI/WEB medium. This is where I think everything will converge at some point. Until next year,.....