From icon-group-sender Tue Jun 29 06:30:06 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Tue, 29 Jun 1993 12:31:14 MST Received: by owl.cs.arizona.edu; Tue, 29 Jun 1993 12:31:13 MST Date: 29 Jun 93 06:30:06 GMT From: amethyst!organpipe.uug.arizona.edu!news@noao.edu (Dave Schaumann) Organization: University of Arizona Subject: Re: Editors Message-Id: <1993Jun29.063006.5754@organpipe.uug.arizona.edu> References: <01GZWHOTQMLY8WW2F1@mis.mcw.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu In article <01GZWHOTQMLY8WW2F1@mis.mcw.edu>, TENAGLIA@mis (Chris Tenaglia - 257-8765) writes: > >Editors are nearly a religious topic in computerdom. I have found a >a few that available on nearly everything I access. But just in case, >I did write one in Icon. I took the Icon class at the U of A last semester, and for the class project, I wrote an editor (in Icon, of course). It was something of an eye-opening experience for me. Editors are deceptively simple. Virtually all they do (certainly at a visible level) can be described by the simplest of algorithms. But... they do so many things. They manage operations on a block of text. In the case of emacs, potentially many blocks of text. And of course, all those operations have to be echoed on the display. And multiple windows visible on the screen. And simultaneous updates when the same buffer is visible in several windows. And X support. And termcap support. Etc, etc, etc. GNUemacs is large, and with good reason. It's got lots to do. I discovered that even what I would consider to be a minimally functional screen editor has got lots to do. Even when you're using a language that's got a strong string type, with lists and tables and sets built-in. -- Hey, everybody -- somebody said `mattress' to Mr. Lambert! TWICE! From icon-group-sender Wed Jun 30 16:35:14 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Wed, 30 Jun 1993 15:48:54 MST Received: by owl.cs.arizona.edu; Wed, 30 Jun 1993 15:48:53 MST Date: Wed, 30 Jun 93 16:35:14 EDT From: Paul_Abrahams@MTS.cc.Wayne.edu To: icon-group@cs.arizona.edu Message-Id: <692691@MTS.cc.Wayne.edu> Subject: Tables versus lists Status: R Errors-To: icon-group-errors@cs.arizona.edu Suppose that I have a "growing array" whose elements I frequently reference. I can implement that array in Icon in either of two ways: as a list or as a table. The construct for referencing an array element is the same in either case: array[n]. The constructs for adding an element are different, but not that different: push(array, element) versus array[integer(*array+1)] := element My question is: how do the efficiencies of these constructs compare? I know that lists are implemented efficiently if allocated all at once, but how about the case where they grow an element at a time? If finding an element requires a search down a linked list with hundreds of items, the table is clearly preferable; but if finding an element in the list can be done with an integer-indexed lookup, the list is clearly preferable. This is a good example of a choice in Icon that is difficult to make intelligently without a knowledge of the implementation and that can make a great difference in performance. Paul Abrahams Reply-To: abrahams@acm.org From icon-group-sender Wed Jun 30 16:12:52 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Wed, 30 Jun 1993 18:02:39 MST Received: by owl.cs.arizona.edu; Wed, 30 Jun 1993 18:02:38 MST Date: Wed, 30 Jun 1993 16:12:52 MST From: "Clint Jeffery" Message-Id: <199306302312.AA27120@chuckwalla.cs.arizona.edu> To: Paul_Abrahams@MTS.cc.Wayne.edu Cc: icon-group@cs.arizona.edu In-Reply-To: Paul_Abrahams@MTS.cc.Wayne.edu's message of Wed, 30 Jun 93 16:35:14 EDT <692691@MTS.cc.Wayne.edu> Subject: Re: Tables versus lists Status: R Errors-To: icon-group-errors@cs.arizona.edu Paul Abrahams writes, regarding: push(array, element) versus array[integer(*array+1)] := element My question is: how do the efficiencies of these constructs compare? Why not run timings and tell us? Detailed knowledge of the implementation helps make guesses, but in Icon the measured results often bely intuition. Regarding the implementation, the "linked list" that is traversed for each list index operation is typically only of length log(*L) and performs very well. But the implementation of tables in Icon is awfully clever (thanks to Bill Griswold and Gregg Townsend). My intuition is that the cost of the integer(*array+1) expression is what turns the tables. By the way, do you really need that function call to integer() there? Clint Jeffery From icon-group-sender Wed Jun 30 17:07:59 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Wed, 30 Jun 1993 18:03:29 MST Received: by owl.cs.arizona.edu; Wed, 30 Jun 1993 18:03:28 MST Date: Wed, 30 Jun 93 17:07:59 -0700 From: wgg@cs.ucsd.edu (William Griswold) Message-Id: <9307010007.AA04348@gremlin> To: abrahams@acm.org, icon-group@cs.arizona.edu Subject: Re: Tables versus lists Status: R Errors-To: icon-group-errors@cs.arizona.edu Paul, Arrays in Icon are allocated in segments that double the size of the array, so that look ups are on average logarithmic in time for random access. The logarithmic behavior does not show up until arrays are rather large. Array elements are generated in constant time. Table elements are generated in basically constant time up to a certain size, whereafter you will see a linear degradation. The degradation point depends on the implementation, but it is rarely a concern for the programmer. I would use arrays and switch later if necessary. Since their syntax is very similar for most operations, making the change should not be difficult. If it would be, you could encapsulate the syntax of the data structure accesses with procedures. In fact, you don't need to know the implementation in most cases: a simple statement of the computational complexity of key operations is sufficient. Bill Griswold UCSD >From: Paul_Abrahams@MTS.cc.Wayne.edu > >Suppose that I have a "growing array" whose elements I frequently >reference. I can implement that array in Icon in either of two ways: as >a list or as a table. The construct for referencing an array element is >the same in either case: array[n]. The constructs for adding an element >are different, but not that different: > push(array, element) >versus > array[integer(*array+1)] := element > >My question is: how do the efficiencies of these constructs compare? I >know that lists are implemented efficiently if allocated all at once, but >how about the case where they grow an element at a time? If finding an >element requires a search down a linked list with hundreds of items, the >table is clearly preferable; but if finding an element in the list can be >done with an integer-indexed lookup, the list is clearly preferable. > >This is a good example of a choice in Icon that is difficult to make >intelligently without a knowledge of the implementation and that can make >a great difference in performance. > >Paul Abrahams >Reply-To: abrahams@acm.org From icon-group-sender Thu Jul 1 13:56:09 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Thu, 1 Jul 1993 15:46:42 MST Received: by owl.cs.arizona.edu; Thu, 1 Jul 1993 15:46:40 MST Date: Thu, 1 Jul 93 13:56:09 PDT From: alex@laguna.Metaphor.COM (Bob Alexander) Message-Id: <9307012056.AA00256@laguna.Metaphor.COM> To: icon-group@cs.arizona.edu Subject: Re: Tables versus lists Status: R Errors-To: icon-group-errors@cs.arizona.edu Just a couple of comments: Last time I looked at the implementation, copy(L) creates a non-linked version of list L, at least until the next time you extend it. Depending on the dynamics of a program, it's possible that the expense of copying a list might pay off, since all subsequent list accesses would be as fast as they could ever be. Disadvantages: it takes twice the space of the list, momentarily, to make the copy and, or course, it takes time to copy it. Also, reliance on "undocumented" behavior such as this can result in surprises in the future. Although tables are implemented very nicely, remember that additional space is required for keys and hash info. -- Bob Alexander Metaphor Computer Systems (415) 966-0751 alex@metaphor.com ====^=== Mountain View, CA ...{uunet}!{decwrl,apple}!metaphor!alex From icon-group-sender Tue Jul 6 16:43:02 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Tue, 6 Jul 1993 15:47:57 MST Received: by owl.cs.arizona.edu; Tue, 6 Jul 1993 15:47:56 MST Date: Tue, 6 Jul 93 16:43:02 EDT From: Paul_Abrahams@MTS.cc.Wayne.edu To: icon-group@cs.arizona.edu Message-Id: <696063@MTS.cc.Wayne.edu> Subject: Transmitting values to co-expressions Status: R Errors-To: icon-group-errors@cs.arizona.edu The section of the Icon book that discusses transmission of values to co-expressions (p. 117) contains a non-obvious example of how transmission works, and also comments that it's very hard and perhaps not possible to find simple and well-motivated examples. Well, recently I came upon a case where transmission of values to co-expressions is both useful and (reasonably) transparent. It's easy enough to program a recursive procedure for writing the representation of an expression. Wherever there are some characters to be generated, you just do "write" of those characters. But suppose, instead, that you want to produce the =string image= of that expression. You can, of course, pass values back up the recursive chain, but that is less satisfying aesthetically. What you really want to do is to write those values to a string, rather like the sprintf function in C. Co-expressions provide a rather neat way of doing this. You create a co-expression for generating the characters and then call it repeatedly, each time concatenating its results onto a string. Within the generator, each time characters are to be output, you pass them to @source. The following program illustrates the method: procedure main() gen := create numbers() result := "" while result ||:= @gen write(result) end procedure numbers() every ((i := 1 to 10) || ",") @ &source end This program will set =result= to "1,2,3,4,5,6,7,8,9,10," and then write it out. Although =numbers= is nonrecursive, it could just as well be recursive. Note that this program does the same thing as the following one: procedure main() numbers() write() end procedure numbers() every writes((i := 1 to 10) || ",") end Paul Abrahams Reply-To: abrahams@acm.org From icon-group-sender Sun Jul 11 12:47:22 1993 Received: by cheltenham.cs.arizona.edu; Sun, 11 Jul 1993 10:14:14 MST Date: Sun, 11 Jul 93 12:47:22 EDT From: Paul_Abrahams@MTS.cc.Wayne.edu To: icon-group@cs.arizona.edu Message-Id: <699110@MTS.cc.Wayne.edu> Subject: Sort enhancements for records and lists Status: R Errors-To: icon-group-errors@cs.arizona.edu I'd like to revisit a question that I know has come up before: enhancing the sort function to provide a useful treatment of records and lists. First, a general observation: the current definition of record sorting is that records are sorted in order of their creation times. Lists are treated similarly. It's hard to imagine how that ordering can be put to a useful purpose. Therefore it's reasonable to treat the ordering of records and lists during sorting as being undefined and thus available for redefinition. Defining an order (however that is done) is very unlikely to invalidate any existing programs. The obvious rule for sorting lists is that they are sorted by their first element; within equal first elements, by their second element, and so forth. This simple extension would provide multi-field sorting, something that many people have requested. Records can be sorted by the same rule, treating records (regardless of their types) as lists of their components. Since there is no obvious ordering among different record types, this treatment is as good as any; sorting collections of records of diverse types is not particularly useful. Since &null already comes first in sort order, missing elements always sort ahead of elements that were given explicitly without any special provisions (for both records and lists). It's worth noting that this multi-field sort does have its limitations. In particular, it doesn't provide for sorting some fields in increasing order and others in decreasing order. (If all fields are in decreasing order, the desired result can be gotten by reversing the list produced by sorting in increasing order.) This deficiency could be gotten round by providing a fourth argument, a list of "+"s and "-"s, that specifies the direction of sorting consecutive fields. All this is modulo the standard observation that the Icon Project has limited resources and implements only those enhancements that it considers worth the expenditure of those resources. Paul Abrahams Reply-To: abrahams@acm.org From icon-group-sender Sun Jul 11 10:50:13 1993 Received: by cheltenham.cs.arizona.edu; Sun, 11 Jul 1993 11:42:13 MST Date: Sun, 11 Jul 1993 10:50:13 MST From: "Gregg Townsend" Message-Id: <199307111750.AA26383@owl.cs.arizona.edu> To: icon-group Subject: Re: Sort enhancements for records and lists Status: R Errors-To: icon-group-errors@cs.arizona.edu From: Paul_Abrahams@MTS.cc.Wayne.edu ...records are sorted in order of their creation times. Lists are treated similarly. It's hard to imagine how that ordering can be put to a useful purpose. Not at all. Creation order often relates directly to something significant such as order of appearance in an input file. I have written programs that make use of the defined order. The obvious rule for sorting lists is that they are sorted by their first element.... As soon as you start looking inside the lists and records you get into potential recursion problems. For example, how would you order two lists, each of which contains the *other* list as the first and only element? Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 602 621 4325 gmt@cs.arizona.edu 110 57 16 W / 32 13 45 N / +758m From icon-group-sender Sun Jul 11 13:53:35 1993 Received: by cheltenham.cs.arizona.edu; Sun, 11 Jul 1993 12:58:27 MST Date: Sun, 11 Jul 93 13:53:35 CDT From: "Richard L. Goerwitz" Message-Id: <9307111853.AA17772@midway.uchicago.edu> To: Paul_Abrahams@mts.cc.wayne.edu Subject: Re: Sort enhancements for records and lists Cc: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu >The obvious rule for sorting lists is that they are sorted by their first >element; within equal first elements, by their second element, and so >forth. This simple extension would provide multi-field sorting, >something that many people have requested. There is a function, sortf, that sorts on a requested field. I wrote a procedure a while back that will sort on arbitrarily many fields, in order. It's called sortff(). If, say, you want lists sorted on field 3, then (if several lists have the same field 3) on field 4, you'd say sortff(l, 3, 4). If anyone wants me to post sortff() will do so. It is not very long. Full recursive sorts on all structures tend to be expensive, and only rarely necessary (in my experience). Paul, I'm like you in the sense that I treat the sort order for struc- tures as undefined, even though a version or so ago the Icon Project define a full sort order for all objects. -Richard goer@midway.uchicago.edu From icon-group-sender Sat Jul 10 02:33:17 1993 Received: by cheltenham.cs.arizona.edu; Mon, 12 Jul 1993 09:43:26 MST Date: 10 Jul 93 02:33:17 GMT From: agate!howland.reston.ans.net!ux1.cso.uiuc.edu!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Subject: Icon-Based Parser Generator -> c.s.m Message-Id: <1993Jul10.023317.22497@midway.uchicago.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Look for Ibpag2 on comp.sources.misc this weekend, or early next week. It seems a lot of people don't get the alt hierarchy, and I've been getting many, many requests for Ibpag2. Seemed sensible to move it to the comp hier- archy. It's had a lot of work, anyway, and probably a new version is needed in place of the old alt.sources version. The README file is still directed at the nontechnical user, and more sample files are included. I have yet to include an ambiguous grammar that really shows off Ibpag2's quasi-GLR parser - mostly because the only working ambiguous grammars I have on hand are for morpho- logical analyzers for Semitic languages, and none are really in a complete enough form that I'd feel right about releasing them. Enjoy. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Mon Jul 12 15:57:36 1993 Received: by cheltenham.cs.arizona.edu; Mon, 12 Jul 1993 14:07:01 MST Date: Mon, 12 Jul 93 15:57:36 CDT From: "Richard L. Goerwitz" Message-Id: <9307122057.AA02178@midway.uchicago.edu> To: icon-group@cs.arizona.edu Subject: sortff Status: R Errors-To: icon-group-errors@cs.arizona.edu I've received several requests for this, so here goes. It's fairly new, and I haven't tested it in a broad range of contexts, so please feel free to post bug fixes or useful modifications.... -Richard ############################################################################ # # Name: sortff.icn # # Title: sortf with multiple field arguments # # Author: Richard L. Goerwitz # # Version: 1.1 # ############################################################################ # # Sortff is like sortf(), except takes an unlimited number of field # arguments. E.g. if you want to sort a list of structures on field # 5, and (for those objects that have the same field 5) do a sub-sort # on field 2, you would use "sortff(list_of_objects, 5, 2)." # ############################################################################ procedure sortff(arglst[]) local sortfield, i, old_i *arglst[1] <= 1 | *arglst = 1 & { return arglst[1] } sortfield := arglst[2] | { return sortf(arglst[1]) } arglst[1] := sortf(arglst[1], sortfield) old_i := 1 every i := old_i+1 to *arglst[1] do { if not (arglst[1][old_i][sortfield] === arglst[1][i][sortfield]) then { return sortff!(push(arglst[3:0], arglst[1][old_i : i])) ||| sortff!(push(arglst[2:0], arglst[1][i : 0])) } } return sortff!(push(arglst[3:0], arglst[1])) end From icon-group-sender Sat Jul 10 17:08:09 1993 Received: by cheltenham.cs.arizona.edu; Wed, 14 Jul 1993 09:46:07 MST Date: 10 Jul 93 17:08:09 GMT From: cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Subject: string replacement routine Message-Id: <1993Jul10.170809.17122@midway.uchicago.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu While I'm working here online, I thought I'd post a utility program I have around that might be of use to some folks. -Richard ############################################################################ # # Name: mapstrs.icn # # Title: map() for strings # # Author: Richard L. Goerwitz # # Version: 1.1 # ############################################################################ # # Mapstrs(s, l1, l2) works like map(), except that instead of taking # ordered character sequences (strings) as arguments 2 and 3, it # takes ordered string sequences (lists). # # Suppose, for example, you wanted to bowdlerize a string by # replacing the words "hell" and "shit" with "heck" and "shoot." You # would call mapstrs as follows: # # mapstrs(s, ["hell", "shit"], ["heck", "shoot"]) # # In order to achieve reasonable speed, mapstrs creates a lot of # static structures, and uses some extra storage. If you want to # replace one string with another, it is overkill. Just use the IPL # replace() routine (in strings.icn). # # If l2 is longer than l1, extra members in l2 are ignored. If l1 is # longer, however, strings in l1 that have no correspondent in l2 are # simply deleted. Mapstr uses a longest-possible-match approach, so # that replacing ["hellish", "hell"] with ["heckish", "heck"] will # work as one would expect. # ############################################################################ # # Links: longstr # ############################################################################ link longstr procedure mapstrs(s, l1, l2) local i, s2 static cs, tbl, last_l1, last_l2 if /l1 | *l1 = 0 then return s if not (last_l1 === l1, last_l2 === l2) then { cs := '' every cs ++:= (!l1)[1] tbl := table() every i := 1 to *l1 do insert(tbl, l1[i], (\l2)[i] | "") } s2 := "" s ? { while s2 ||:= tab(upto(cs)) do s2 ||:= tbl[tab(longstr(l1))] | move(1) s2 ||:= tab(0) } return s2 end -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Tue Jul 20 11:00:24 1993 Received: by cheltenham.cs.arizona.edu; Tue, 20 Jul 1993 08:10:00 MST Date: Tue, 20 Jul 93 11:00:24 EDT From: Paul_Abrahams@MTS.cc.Wayne.edu To: icon-group@cs.arizona.edu Message-Id: <705767@MTS.cc.Wayne.edu> Subject: Mystery about "every" Status: R Errors-To: icon-group-errors@cs.arizona.edu I thought I understood how "every" works -- at least when I check everything out in the book -- but I've come across a program whose behavior leaves me utterly baffled (this under OS/2 V8.8 Icon). Consider the following example, derived from the program where the problem appeared: procedure main() local retval, c, s s := "123" retval := 0 every c := !s do retval := 8 * retval + ord(c) - ord("0") write("Octal output is ", retval) end This program produced the output 83, as expected. But I then replaced the "every" statement by the following one, which I thought to be more elegant: every retval := 8 * retval + ord(!s) - ord("0") Now the output of the program is 3 (the last digit), not 83. Can anyone explain to me what's going on? Thanks. Paul Abrahams Reply-To: abrahams@acm.org From icon-group-sender Tue Jul 20 10:03:18 1993 Received: by cheltenham.cs.arizona.edu; Tue, 20 Jul 1993 13:43:46 MST Message-Id: <9307201701.AA31350@enlil.premenos.sf.ca.us> From: Ken Walker Subject: Re: Mystery about "every" To: icon-group@cs.arizona.edu Date: Tue, 20 Jul 93 10:03:18 PDT In-Reply-To: <705767@MTS.cc.Wayne.edu>; from "Paul_Abrahams@MTS.cc.Wayne.edu" at Jul 20, 93 11:00 am Mailer: Elm [revision: 66.25] Status: R Errors-To: icon-group-errors@cs.arizona.edu > Paul_Abrahams@MTS.cc.Wayne.edu writes > > ... > This program produced the output 83, as expected. But I then replaced > the "every" statement by the following one, which I thought to be more > elegant: > > every retval := 8 * retval + ord(!s) - ord("0") > > Now the output of the program is 3 (the last digit), not 83. Backtracking only goes as far as the generator !s. The expression 8 * retval is not reeveluated. The original value of 0 is used in every iteration. Ken Walker, kwalker@premenos.sf.ca.us From icon-group-sender Tue Jul 20 11:22:30 1993 Received: by cheltenham.cs.arizona.edu; Tue, 20 Jul 1993 13:44:22 MST Message-Id: <9307201822.AA19766@hpclpax.cup.hp.com> To: Paul_Abrahams@MTS.cc.Wayne.edu Cc: icon-group@cs.arizona.edu Subject: Re: Mystery about "every" Date: Tue, 20 Jul 93 11:22:30 -0700 From: Cary Coutant Status: R Errors-To: icon-group-errors@cs.arizona.edu > every retval := 8 * retval + ord(!s) - ord("0") > > Now the output of the program is 3 (the last digit), not 83. > > Can anyone explain to me what's going on? Try reversing the operands of the "+" operation: every retval := ord(!s) - ord("0") + 8 * retval Your problem was that the every was resuming the expression from the last suspended generator, so "8 * retval" was never being reevaluated. In situations like this, it's sometimes useful to replace a built-in operator with your own procedure, so you can see what's going on by setting TRACE. For example: every retval := add(8 * retval, ord(!s) - ord("0")) Cary Coutant Hewlett-Packard California Language Lab From icon-group-sender Tue Jul 20 14:39:42 1993 Received: by cheltenham.cs.arizona.edu; Tue, 20 Jul 1993 19:43:14 MST Date: Tue, 20 Jul 93 14:39:42 PDT From: alex@laguna.Metaphor.COM (Bob Alexander) Message-Id: <9307202139.AA17977@laguna.Metaphor.COM> To: icon-group@cs.arizona.edu Subject: Re: Mystery about "every" Status: R Errors-To: icon-group-errors@cs.arizona.edu >From: Ken Walker >> Paul_Abrahams@MTS.cc.Wayne.edu writes >> >> ... >> This program produced the output 83, as expected. But I then replaced >> the "every" statement by the following one, which I thought to be more >> elegant: >> >> every retval := 8 * retval + ord(!s) - ord("0") >> >> Now the output of the program is 3 (the last digit), not 83. > >Backtracking only goes as far as the generator !s. The expression > > 8 * retval > >is not reeveluated. The original value of 0 is used in every >iteration. Try rephrasing it as: every retval := ord(!s) - ord("0") + 8 * retval It works. You can run into some rather non-intuitive stuff using this "short form" of every -- you have to think hard about the order of evaluation and exactly which parts of the expression will be re-evaluated. Its safer, and probably more transparent, to use the longer form with the auxiliary variable -- but not as cute. -- Bob Alexander Metaphor Computer Systems (415) 966-0751 alex@metaphor.com ====^=== Mountain View, CA ...{uunet}!{decwrl,apple}!metaphor!alex From icon-group-sender Mon Jul 19 21:24:57 1993 Received: by cheltenham.cs.arizona.edu; Tue, 20 Jul 1993 19:43:51 MST Date: 19 Jul 93 21:24:57 GMT From: walter!flaubert!norman@uunet.uu.net (Norman Ramsey) Organization: Bellcore Subject: More on Icon performance Message-Id: <1993Jul19.212457.15962@walter.bellcore.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu I want to create dags, so that I need to check to see if the node I'm about to create already exists. The best way I know of is to create a string that is a function of the node's elements, then look for that string in a table. Does anyone else know a better way? Here's what I'm doing: procedure newitem(nt, dotpos, cat) static cache initial { cache := table() } s := nt || " " || image(cat) || " " || dotpos /cache[s] := item(nt, dotpos, cat) return cache[s] end Can anyone suggest something better? I'm especially interested in something less wasteful of string space. Norman -- Norman Ramsey norman@bellcore.com From icon-group-sender Tue Jul 20 17:55:40 1993 Received: by cheltenham.cs.arizona.edu; Tue, 20 Jul 1993 19:44:18 MST Date: Tue, 20 Jul 93 17:55:40 PDT From: John Paolillo To: icon-group@cs.arizona.edu Cc: empiricists@CSLI.Stanford.EDU Subject: Software information wanted Message-Id: Status: R Errors-To: icon-group-errors@cs.arizona.edu ***Please Post***||***Please Post***||***Please Post*** LANGUAGE-RELATED SOFTWARE PRODUCERS Information wanted The Linguistic Society of America is attempting to build a mailing list of software producers, both commercial and academic, who actively produce software for language-related applications. Specifically we are interested in individuals or companies who are working on any of the following appliactions (or similar ones). o computer-assisted language/linguistic analysis o lexicography o text processing o natural language processing/understanding o speech recognition and synthesis o machine translation o computer text generation o parsing o linguistics courseware o computer assisted language learning/teaching o fonts/typesetting of IPA and linguistic formalisms o any other software involving the analysis of language If you are such a producer, please take the time to provide us with the information indicated below. If you know of another, please pass this request onto them. Send your response via e-mail to *both* zzlsa@gallua.bitnet and johnp@utafll.uta.edu (please include the information headings in your message): ------------------------------------------------- Name: Address: Telephone: Fax: E-mail: Status: (commercial vendor, academic, individual, etc.) Would you be interested in exhibiting software at the Annual Linguistic Society of America meeting (Boston MA, 6-9 Jan. 1994)? (YES/NO) Products: (optional -- for each, indicate the following) Product Name: Product Description: (25 words -- longer descriptions will be truncated) Platform: (PC, Mac, Unix workstation, etc) Price: (free, or approximate price) From icon-group-sender Tue Jul 20 21:35:06 1993 Received: by cheltenham.cs.arizona.edu; Tue, 20 Jul 1993 19:44:55 MST Date: Tue, 20 Jul 93 21:35:06 EDT From: Paul_Abrahams@MTS.cc.Wayne.edu To: icon-group@cs.arizona.edu Message-Id: <706461@MTS.cc.Wayne.edu> Subject: Mysteries of "every" Status: R Errors-To: icon-group-errors@cs.arizona.edu Cary Coutant wrote the following in response to my query: ----------------------------- > every retval := 8 * retval + ord(!s) - ord("0") > > Now the output of the program is 3 (the last digit), not 83. > > Can anyone explain to me what's going on? Try reversing the operands of the "+" operation: every retval := ord(!s) - ord("0") + 8 * retval Your problem was that the every was resuming the expression from the last suspended generator, so "8 * retval" was never being reevaluated. In situations like this, it's sometimes useful to replace a built-in operator with your own procedure, so you can see what's going on by setting TRACE. For example: every retval := add(8 * retval, ord(!s) - ord("0")) ----------------------------------- This explanation satisfies the ultimate test: Cary's version works. Yet I've looked again at pages 15-16 of the Icon book and I still don't get it. The explanation of resumption on p. 15 is in terms of failure, and there's no failure in the expression of my example. The description of "every" on p. 16 says that "expr1 is first evaluated and then repeatedly resumed to produce all its values." I would have thought that resuming an expression that doesn't fail would cause it to be =completely= reevaluated. Clearly the assignment, which is the outermost level of the expression, is evaluated on each iteration. In fact, I verified (by attaching a "do") that with s="123", retval takes on successive values of 1,2,3. Yet the second retval is not being reevaluated. So which parts of an expression are reevaluated and which ones aren't? Is there any way to deduce what happens from the explanation in the Icon book? I'd appreciate any help I can get on this. I'd also suggest that you post your comments to icon-group rather than sending them to me personally. Paul Abrahams Reply-To: abrahams@acm.org From icon-group-sender Sat Jul 17 18:30:06 1993 Received: by cheltenham.cs.arizona.edu; Tue, 20 Jul 1993 19:46:19 MST Date: 17 Jul 93 18:30:06 GMT From: dog.ee.lbl.gov!overload.lbl.gov!agate!spool.mu.edu!uwm.edu!linac!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Subject: Re: Help sought tuning Icon programs Message-Id: <1993Jul17.183006.22395@midway.uchicago.edu> References: <1993Jul17.174448.23138@walter.bellcore.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu norman@flaubert.bellcore.com (Norman Ramsey) writes: > >I have a useful Icon program of about 1400 lines, but its utility is >greatly diminished by its lack of speed. This is a typical problem I have as well. There's always a big ques- tion I have to answer, before writing an application, just how big and slow it will be :-), and hence whether I should take the time and trou- ble to write it in C. If I can, I'll always try to get away with Icon because of the dramatically reduced time it takes to produce and debug working code. Generally, if I'm going to use Icon, there are several things I can do to see if obvious speed improvements can be made. The first is to use the compiler. Much has been made here about the Icon compiler's experi- mental nature, and the existence of bugs in it. I've found, though, that if I can get things compiled on a SPARC, they usually run correctly, and the speed increase can be anywhere from two to a hundredfold. Another useful trick is to run a simple profiler. In the Icon program library, there is a simple program called "profile" that runs under UNIX (and could probably be made to run under any serious operating system). All it does is take an Icon program compiled with the trace option on (icont -t) and perform some rough statistics on what proce- dures are being called the most and from where. It's meant for inter- active use. You can, if you like, use it with programs not compiled with tracing on, but rather with tracing manually set (&trace := -1) at the point in the program where you want to start gathering statistics. A final way of profiling Icon code is to use another Icon Program Lib- rary program called "empg." This is essentially an expression timing utility. You just give it a file containing the expressions you want to time, and it gives you an Icon file that, when run, times those ex- pressions, and then prints a summary of how long they took to run. This is the sort of utility you'd run if you had a question about whether it was significantly faster to do things in a certain way, as compared to some other way. One last recommendation I'd make is that you simply post questions as they arise. This group has a couple of real die-hards, and a lot of bright, interested people. Icon isn't like Pascal or C - you have to have an innovatory or inquisitive spirit to have found out about it, & to have acquired facility with it. The folks who read this group are likely to have some really good suggestions about how to clean up any code you write. A case in point is the sortff routine I posted a while back. Bob Alexander just rewrote it for me for fun (!), and returned a version that runs about five times as fast as my initial version. I took his code, debugged it, and now am testing it out. You'll be seeing it in a couple of days. (Thanks, Bob.) Hope this helps, Norman! -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Wed Jul 21 05:33:19 1993 Received: by cheltenham.cs.arizona.edu; Wed, 21 Jul 1993 05:16:06 MST Date: Wed, 21 Jul 1993 05:33:19 -0400 Message-Id: <9307210933.AA15402@medinah.atc.ucarb.com> To: icon-group@cs.arizona.edu From: far@medinah.atc.ucarb.com (Forrest Richey) Subject: Icon for large linguistic projects Status: R Errors-To: icon-group-errors@cs.arizona.edu Some time ago I re-posted a message from the Linguist List having to do with a linguistic software initiative. I had wondered if (and suggested that) Icon might become more 'popular' by showing utility in such an initiative. One reply claimed that Icon would not have such utility since it could not manage the massive amounts of data/calculations that are often required in linguistic work. Since there is a UNIX version, I wondered if Icon might have such capability after all. And since I didn't see any replies to this assertion, I'm asking if it's true. (Since I didn't keep the original message, I can't be more specific.) Sincerely, Forrest far@medinah.atc.ucarb.com From icon-group-sender Wed Jul 21 06:12:42 1993 Received: by cheltenham.cs.arizona.edu; Wed, 21 Jul 1993 08:43:02 MST Message-Id: <9307211312.AA03386@orpheus.tuc.noao.edu> From: swampler@noao.edu (Steve Wampler) Date: Wed, 21 Jul 1993 06:12:42 MST In-Reply-To: Paul_Abrahams@MTS.cc.Wayne.edu's mail message of Jul 20, 9:35pm. X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: icon-group@cs.arizona.edu Subject: Re: Mysteries of "every" Status: R Errors-To: icon-group-errors@cs.arizona.edu On Jul 20 at 9:35pm, Paul_Abrahams@MTS.cc.Wayne.edu writes: } } Cary Coutant wrote the following in response to my query: } ----------------------------- } > every retval := 8 * retval + ord(!s) - ord("0") } > } > Now the output of the program is 3 (the last digit), not 83. } > } > Can anyone explain to me what's going on? } } Try reversing the operands of the "+" operation: } } every retval := ord(!s) - ord("0") + 8 * retval } } Your problem was that the every was resuming the expression } from the last suspended generator, so "8 * retval" was never } being reevaluated. } } In situations like this, it's sometimes useful to replace a } built-in operator with your own procedure, so you can see } what's going on by setting TRACE. For example: } } every retval := add(8 * retval, ord(!s) - ord("0")) } ----------------------------------- } } This explanation satisfies the ultimate test: Cary's version works. } } Yet I've looked again at pages 15-16 of the Icon book and I still don't } get it. The explanation of resumption on p. 15 is in terms of failure, } and there's no failure in the expression of my example. The description } of "every" on p. 16 says that "expr1 is first evaluated and then } repeatedly resumed to produce all its values." I would have thought that } resuming an expression that doesn't fail would cause it to be } =completely= reevaluated. } } Clearly the assignment, which is the outermost level of the expression, } is evaluated on each iteration. In fact, I verified (by attaching a } "do") that with s="123", retval takes on successive values of 1,2,3. Yet } the second retval is not being reevaluated. So which parts of an } expression are reevaluated and which ones aren't? Is there any way to } deduce what happens from the explanation in the Icon book? } } I'd appreciate any help I can get on this. I'd also suggest that you } post your comments to icon-group rather than sending them to me } personally. } Well, actually, there *is* a failure. It's inherent in the semantics of every. For all practical purposes, every expr is equivalent to: (expr) & &fail (It gets a little trickier to describe the behavior when a 'do clause' is present, of if there is a 'break' or 'next' in the expr....). 'Resumption' is also always a LIFO operation on generators, whether you care to think of every as above or as a separately semantic concept. It is fundamentally different than 'reevaluation'. If you were to try and develop a non-LIFO model for resumption, it gets *very* tricky to still guarantee the combinatorial effects of multiple generators. In particular, you cannot use a stack based evaluation model. Note that you can experiment with other models for resumption with Co-expressions, if you want to see what problems arise! ~t -- Steve Wampler swampler@noao.edu Gemini Project (under AURA) From icon-group-sender Wed Jul 21 09:13:07 1993 Received: by cheltenham.cs.arizona.edu; Wed, 21 Jul 1993 08:44:20 MST Date: Wed, 21 Jul 93 09:13:07 CDT From: "Richard L. Goerwitz" Message-Id: <9307211413.AA01333@midway.uchicago.edu> To: icon-group@cs.arizona.edu Subject: Icon for large-scale stuff Status: R Errors-To: icon-group-errors@cs.arizona.edu >Some time ago I re-posted a message from the Linguist List having to do >with a linguistic software initiative. I had wondered if (and suggested >that) Icon might become more 'popular' by showing utility in such an >initiative. >One reply claimed that Icon would not have such utility since it could not >manage the massive amounts of data/calculations that are often required in >linguistic work. Sounds pretty pessimistic. In fact, I've been using Icon successfully on large corpora for several years now. Naturally there are some things Icon does not do well. Despite the natural tendency to be lazy, one really does have to maintain facility with several languages, both high and low-level, in order to be construct NLP tools quickly that can do the job. One thing to remember is that NL stuff often involves constructing human- machine interfaces. The software only has to be fast enough to map NL queries to some primitive set of instructions. This can be done in real time using Icon-based tools. NLP also may involve processing large cor- pora in batch mode. Again, although Icon will not do this sort of thing as quickly as C, it's certainly no worse than LISP or Prolog, and these are two of the main languages used for such batch processing. The idea is that it doesn't matter if the batch processing finishes in one minute or ten if it's really done in batch mode. Response time is a problem more for interactive systems. One final note I might inject here is that Icon performs perfectly well for multi-megabyte databases, especially under "real" operating systems with sensible file systems. If you want evidence of this, ftp my silly "Bibleref" program from cs.arizona.edu. This program can find a passage requested by the user, decompress it, and display it in just a few sec- onds. It can perform word searches almost as quickly (unless you are looking for something like "the"). If I'd skipped the compression and decompression phases by using a straight, human-readable database, then the delays would have been even less. I confess that there are certain projects I really wouldn't do in Icon. I discovered one seemingly complex phenomenon in one text to be, in fact, *almost* right linear, and decided that the natural parsing tool to use would be YACC + Lex. Still, it is flatly wrong to claim that Icon would not be useful as a linguistic research tool. The proof is in the pudding, and I have a lot of pudding on hand. -Richard Goerwitz goer@midway.uchicago.edu From icon-group-sender Wed Jul 21 09:14:42 1993 Received: by cheltenham.cs.arizona.edu; Wed, 21 Jul 1993 10:50:32 MST Message-Id: <9307211612.AA52197@enlil.premenos.sf.ca.us> From: Ken Walker Subject: compiler performance To: icon-group@cs.arizona.edu Date: Wed, 21 Jul 93 9:14:42 PDT Mailer: Elm [revision: 66.25] Status: R Errors-To: icon-group-errors@cs.arizona.edu > Richard L. Goerwitz writes: > > ... The first is to use the compiler. ... and the speed increase > can be anywhere from two to a hundredfold. *********** ? Wow, the most I every got was a factor of around 30 for procedure main() every i := 1 to 1000000 end which I had reasons to expect would be optimized about as much as anything. Richard may have more practical experience with the compiler than I have (even though I wrote it :-), but I think a factor of two to four is more typical. Of course, a speed increase of a factor of four or so can certain make the difference with some programs between being usable and not. And your favorite program might be one of those that gets optimized even more. (For the record, I like Richards claim better than mine :-) Ken Walker, kwalker@premenos.sf.ca.us From icon-group-sender Wed Jul 21 08:48:31 1993 Received: by cheltenham.cs.arizona.edu; Wed, 21 Jul 1993 10:50:24 MST Message-Id: <9307211546.AA32785@enlil.premenos.sf.ca.us> From: Ken Walker Subject: Re: Mysteries of "every" To: icon-group@cs.arizona.edu Date: Wed, 21 Jul 93 8:48:31 PDT In-Reply-To: <706461@MTS.cc.Wayne.edu>; from "Paul_Abrahams@MTS.cc.Wayne.edu" at Jul 20, 93 9:35 pm Mailer: Elm [revision: 66.25] Status: R Errors-To: icon-group-errors@cs.arizona.edu > Paul Abrahams (abrahams@acm.org) writes: > > Yet I've looked again at pages 15-16 of the Icon book and I still don't > get it. The explanation of resumption on p. 15 is in terms of failure, > and there's no failure in the expression of my example. The description > of "every" on p. 16 says that "expr1 is first evaluated and then > repeatedly resumed to produce all its values." I would have thought that > resuming an expression that doesn't fail would cause it to be > =completely= reevaluated. The expression every acts the same as & &fail (unless contains break or continue). failure and resumption are two halves of the same thing. When something fails it initiates backtracking and backtracking ends with something being resumed (or by leaving a bounded expression). While "every" may not be described in terms of failure, it does initiate backtracking exactly the way failure does. To understand what gets recomputed and what does not you need to think in terms of executation order. It may help to convert an expression into a postfix notation. Your expression every retval := 8 * retval + ord(!s) - ord("0") might be converted into someting like the following. "Normal" execution is left to right and backtracking is right to left. Backtracking ends as soon as it finds something to resume. When the resumed operation produces another value execution continues forward again. (retval ((((8 retval *) (ord (s !) invoke1)) +) (ord "0" invoke1) -) :=) every ******************************* ^ | * | | * -------------------------------------------- not recomputed backtracking loop, recomputed Does this help? Ken Walker, kwalker@premenos.sf.ca.us From icon-group-sender Mon Jul 19 04:34:06 1993 Received: by cheltenham.cs.arizona.edu; Thu, 22 Jul 1993 12:26:30 MST Date: 19 Jul 93 04:34:06 GMT From: cis.ohio-state.edu!math.ohio-state.edu!darwin.sura.net!haven.umd.edu!cs.umd.edu!uchinews!quads!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Subject: new sortff Message-Id: <1993Jul19.043406.17331@midway.uchicago.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu As promised: ############################################################################ # # Name: sortff.icn # # Title: sortf with multiple field arguments # # Author: Bob Alexander and Richard L. Goerwitz # # Date: July 14, 1993 # ############################################################################ # # Sortff is like sortf(), except takes an unlimited number of field # arguments. E.g. if you want to sort a list of structures on field # 5, and (for those objects that have the same field 5) do a sub-sort # on field 2, you would use "sortff(list_of_objects, 5, 2)." # ############################################################################ # # sortff: structure [x integer [x integer...]] -> structure # (L, fields...) -> new_L # # Where L is any subscriptable structure, and fields are any # number of integer subscripts in any desired order. Returns # a copy of structure L with its elements sorted on fields[1], # and, for those elements having an identical fields[1], sub- # sorted on field[2], etc. # procedure sortff(L, fields[]) *L <= 1 & { return copy(L) } return sortff_1(L, fields, 1, []) end procedure sortff_1(L, fields, k, uniqueObject) local sortField, cachedKeyValue, i, startOfRun, thisKey sortField := fields[k] L := sortf(L, sortField) # initial sort using fields[k] # # If more than one sort field is given, use each field successively # as the current key, and, where members in L have the same value for # this key, do a subsort using fields[k+1]. # if fields[k +:= 1] then { # # Set the equal-key-run pointer to the start of the list and # save the value of the first key in the run. # startOfRun := 1 cachedKeyValue := L[startOfRun][sortField] | uniqueObject every i := 2 to *L do { thisKey := L[i][sortField] | uniqueObject if not (thisKey === cachedKeyValue) then { # # We have an element with a sort key different from the # previous. If there's a run of more than one equal keys, # sort the sublist. # if i - startOfRun > 1 then { L := L[1:startOfRun] ||| sortff_1(L[startOfRun:i], fields, k, uniqueObject) ||| L[i:0] } # Reset the equal-key-run pointer to this key and cache. startOfRun := i cachedKeyValue := L[startOfRun][sortField] | uniqueObject } } # # Sort a final run if it exists. # if i - startOfRun > 1 then { L := L[1:startOfRun] ||| sortff_1(L[startOfRun:0], fields, k, uniqueObject) } } return L end -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Thu Jul 22 12:40:36 1993 Received: by cheltenham.cs.arizona.edu; Thu, 22 Jul 1993 12:27:11 MST Message-Id: <9307221702.AA20596@uu3.psi.com> Date: Thu, 22 Jul 93 12:40:36 EDT From: Jerry Leichter To: ICON-GROUP@cs.arizona.edu Subject: RE: More on Icon performance X-Vms-Mail-To: UUCP%"walter!flaubert!norman@uunet.uu.net" Status: R Errors-To: icon-group-errors@cs.arizona.edu I want to create dags, so that I need to check to see if the node I'm about to create already exists. The best way I know of is to create a string that is a function of the node's elements, then look for that string in a table. Does anyone else know a better way? Here's what I'm doing: procedure newitem(nt, dotpos, cat) static cache initial { cache := table() } s := nt || " " || image(cat) || " " || dotpos /cache[s] := item(nt, dotpos, cat) return cache[s] end Can anyone suggest something better? I'm especially interested in something less wasteful of string space. What you are using is an inefficient variation of a classic, efficient tech- nique used in compilers that goes under the name of value numbering. It arises in common subexpression removal. Suppose you had a tree representing an expression, and wished to find all common subexpressions within it. A common subexpression would be a subtree whose leaves were all leaves of the original tree. Assign to each node in the tree a value as follows: If the node is a leaf, assign it a unique value based on what the leaf contains. (In the compiler context, a leaf is either a variable or a constant. The value represents the particular value or constant.) If the node is of the form [v1,...,vn], where the vi's are the value numbers of then node's n children, assign a value f(v1,...,vn), which is unique among all the value numbers chosen for the leaves, and among all values for f with different sets of arguments. Then two nodes represent common subexpressions if and only if they have the same value number. What you are doing is using "value numbers" that are not numbers, but strings; and you are using image() for f(), and at the leaves. While this works, as you note it's expensive. If you use numerical values, it's much easier to build small data strutures in which you can look things up quickly. (f() is almost always computed by (a) looking up [v1,...,vn] in an appropriate table - usually a hash table, but some kind of trie might make sense; (b) if the node isn't already in the table, incrementing a counter and assigning its value as the value number. Given the nature of the leaves in a compiler, it's usually easy to come up with simple value numbers for them directly.) You'll need some way to distinguish between leaves, which you could still look up using image(), and interior nodes; and you'd need some representation of [v1,...,vn]. It's unclear from your code, but if indeed you are only concerned with binary nodes, and your data structures aren't too large, then you might be able to get away with 16-bitf value numbers, and represent [v1,v2] as 2^16*v1+v2, which can be computed and looked up in a table very quickly. More generally, a list would probably make more sense. If certain nodes in the tree have appropriate mathematical properties, it's possible to adjust the value numbering algorithm to make use of them. For example, if we consider "+" to be commutative, so that "a+b" and "b+a" are to be considered the same subexpression, then we can choose f() so that f(+,v1,v2) = f(+,v2,v1). (Generally you'd do this by exchanging f's second and third arguments before computing it if, say, the second is larger than the third.) Without knowing anything about your application, it's impossible to say whether this trick might be useful. -- Jerry From icon-group-sender Tue Jul 27 17:59:05 1993 Received: by cheltenham.cs.arizona.edu; Wed, 28 Jul 1993 05:20:55 MST Date: 27 Jul 93 17:59:05 GMT From: tyrolia!jmd@princeton.edu (John M. Danskin) Organization: Princeton University CS Department, Princeton NJ Subject: flushing files in icon Message-Id: <1993Jul27.175905.28820@Princeton.EDU> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Is there a way to flush files in icon? I eventually found NOERRBUF for stderr, but it'd be nice to have more control... thanks! -- John Danskin | Computer Science Graduate Student (609) 258-5386 | Graphics systems: network graphics & m-media (609) 258-1771 fax | Escape from Princeton planned 8/94. jmd@cs.princeton.edu | Flyfishing: any fly, any fish. From icon-group-sender Tue Jul 27 19:05:26 1993 Received: by cheltenham.cs.arizona.edu; Wed, 28 Jul 1993 12:51:58 MST Date: 27 Jul 93 19:05:26 GMT From: agate!spool.mu.edu!uwm.edu!linac!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Subject: flushing files; tokenizing Message-Id: <1993Jul27.190526.27013@midway.uchicago.edu> References: <1993Jul27.175905.28820@Princeton.EDU> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Re flushing files: As of 8.8 or 8.10 you can flush files in Icon. There's a new built-in function to do it called, as you'd expect, flush(). Apparently you weren't the only one who felt this need. On another subject, here's another version of the Icon tokenizing procedure I posted a while back. This one has a few bugs fixed, and has a few more options. I'm posting this now in toto, but I may post diffs from here on, depending on how great the changes are. -Richard ############################################################################ # # Name: itokens.icn # # Title: itokens (Icon source-file tokenizer) # # Author: Richard L. Goerwitz # # Version: 1.11 # ############################################################################ # # This file contains itokens() - a utility for breaking Icon source # files up into individual tokens. This is the sort of routine one # needs to have around when implementing things like pretty printers, # preprocessors, code obfuscators, etc. It would also be useful for # implementing cut-down implementations of Icon written in Icon - the # sort of thing one might use in an interactive tutorial. # # Itokens(f, x) takes, as its first argument, f, an open file, and # suspends successive TOK records. TOK records contain two fields. # The first field, sym, contains a string that represents the name of # the next token (e.g. "CSET", "STRING", etc.). The second field, # str, gives that token's literal value. E.g. the TOK for a literal # semicolon is TOK("SEMICOL", ";"). For a mandatory newline, itokens # would suspend TOK("SEMICOL", "\n"). # # Unlike Icon's own tokenizer, itokens() does not return an EOFX # token on end-of-file, but rather simply fails. It also can be # instructed to return syntactically meaningless newlines by passing # it a nonnull second argument (e.g. itokens(infile, 1)). These # meaningless newlines are returned as TOK records with a null sym # field (i.e. TOK(&null, "\n")). # # NOTE WELL: If new reserved words or operators are added to a given # implementation, the tables below will have to be altered. Note # also that &keywords should be implemented on the syntactic level - # not on the lexical one. As a result, a keyword like &features will # be suspended as TOK("CONJUNC", "&") and TOK("IDENT", "features"). # ############################################################################ # # Links: slshupto # # Requires: coexpressions # ############################################################################ #link ximage, slshupto link slshupto #make sure you have version 1.2 or above global next_c, line_number record TOK(sym, str) # # main: an Icon source code uglifier # # Stub main for testing; uncomment & compile. The resulting # executable will act as an Icon file compressor, taking the # standard input and outputting Icon code stripped of all # unnecessary whitespace. Guaranteed to make the code a visual # mess :-). # #procedure main() # # local separator, T # separator := "" # every T := itokens(&input) do { # if any(&digits ++ &letters ++ '_.', \T.str, 1, 2) & \T.sym ~== "DOT" # then writes(separator) # if T.sym == "SEMICOL" then writes(";") else writes(T.str) # if any(&digits ++ &letters ++ '_.', \T.str, -1, 0) & \T.sym ~== "DOT" # then separator := " " else separator := "" # } # #end # # itokens: file x anything -> TOK records (a generator) # (stream, nostrip) -> Rs # # Where stream is an open file, anything is any object (it only # matters whether it is null or not), and Rs are TOK records. # Note that itokens strips out useless newlines. If the second # argument is nonnull, itokens does not strip out superfluous # newlines. It may be useful to keep them when the original line # structure of the input file must be maintained. # procedure itokens(stream, nostrip) local T, last_token # initialize to some meaningless value last_token := TOK() every T := \iparse_tokens(stream) do { if \T.sym then { if T.sym == "EOFX" then fail else { # # If the last token was a semicolon, then interpret # all ambiguously unary/binary sequences like "**" as # beginners (** could be two unary stars or the [c]set # intersection operator). # if \last_token.sym == "SEMICOL" then suspend last_token := expand_fake_beginner(T) else suspend last_token := T } } else { if \nostrip then suspend last_token := T } } end # # expand_fake_beginner: TOK record -> TOK records # # Some "beginner" tokens aren't really beginners. They are token # sequences that could be either a single binary operator or a # series of unary operators. The tokenizer's job is just to snap # up as many characters as could logically constitute an operator. # Here is where we decide whether to break the sequence up into # more than one op or not. # procedure expand_fake_beginner(next_token) static exptbl initial { exptbl := table() insert(exptbl, "CONCAT", [TOK("BAR", "|"), TOK("BAR", "|")]) insert(exptbl, "DIFF", [TOK("MINUS", "-"), TOK("MINUS", "-")]) insert(exptbl, "EQUIV", [TOK("NUMEQ", "="), TOK("NUMEQ", "="), TOK("NUMEQ", "=")]) insert(exptbl, "INTER", [TOK("STAR", "*"), TOK("STAR", "*")]) insert(exptbl, "LCONCAT", [TOK("BAR", "|"), TOK("BAR", "|"), TOK("BAR", "|")]) insert(exptbl, "LEXEQ", [TOK("NUMEQ", "="), TOK("NUMEQ", "=")]) insert(exptbl, "LEXNE", [TOK("TILDE", "~"), TOK("NUMEQ", "="), TOK("NUMEQ", "=")]) insert(exptbl, "NOTEQUIV",[TOK("TILDE", "~"), TOK("NUMEQ","="), TOK("NUMEQ", "="), TOK("NUMEQ", "=")]) insert(exptbl, "NUMNE", [TOK("TILDE", "~"), TOK("NUMEQ","=")]) insert(exptbl, "UNION", [TOK("PLUS", "+"), TOK("PLUS", "+")]) } if \exptbl[next_token.sym] then suspend !exptbl[next_token.sym] else return next_token end # # iparse_tokens: file -> TOK records (a generator) # (stream) -> tokens # # Where file is an open input stream, and tokens are TOK records # holding both the token type and actual token text. # # TOK records contain two parts, a preterminal symbol (the first # "sym" field), and the actual text of the token ("str"). The # parser only pays attention to the sym field, although the # strings themselves get pushed onto the value stack. # # Note the following kludge: Unlike real Icon tokenizers, this # procedure returns syntactially meaningless newlines as TOK # records with a null sym field. Normally they would be ignored. # I wanted to return them so they could be printed on the output # stream, thus preserving the line structure of the original # file, and making later diagnostic messages more usable. # procedure iparse_tokens(stream, getchar) local elem, whitespace, token, last_token, primitives, reserveds static be_tbl, reserved_tbl, operators initial { # Primitive Tokens # primitives := [ ["identifier", "IDENT", "be"], ["integer-literal", "INTLIT", "be"], ["real-literal", "REALLIT", "be"], ["string-literal", "STRINGLIT", "be"], ["cset-literal", "CSETLIT", "be"], ["end-of-file", "EOFX", "" ]] # Reserved Words # reserveds := [ ["break", "BREAK", "be"], ["by", "BY", "" ], ["case", "CASE", "b" ], ["create", "CREATE", "b" ], ["default", "DEFAULT", "b" ], ["do", "DO", "" ], ["else", "ELSE", "" ], ["end", "END", "b" ], ["every", "EVERY", "b" ], ["fail", "FAIL", "be"], ["global", "GLOBAL", "" ], ["if", "IF", "b" ], ["initial", "INITIAL", "b" ], ["invocable", "INVOCABLE", "" ], ["link", "LINK", "" ], ["local", "LOCAL", "b" ], ["next", "NEXT", "be"], ["not", "NOT", "b" ], ["of", "OF", "" ], ["procedure", "PROCEDURE", "" ], ["record", "RECORD", "" ], ["repeat", "REPEAT", "b" ], ["return", "RETURN", "be"], ["static", "STATIC", "b" ], ["suspend", "SUSPEND", "be"], ["then", "THEN", "" ], ["to", "TO", "" ], ["until", "UNTIL", "b" ], ["while", "WHILE", "b" ]] # Operators # operators := [ [":=", "ASSIGN", "" ], ["@", "AT", "b" ], ["@:=", "AUGACT", "" ], ["&:=", "AUGAND", "" ], ["=:=", "AUGEQ", "" ], ["===:=", "AUGEQV", "" ], [">=:=", "AUGGE", "" ], [">:=", "AUGGT", "" ], ["<=:=", "AUGLE", "" ], ["<:=", "AUGLT", "" ], ["~=:=", "AUGNE", "" ], ["~===:=", "AUGNEQV", "" ], ["==:=", "AUGSEQ", "" ], [">>=:=", "AUGSGE", "" ], [">>:=", "AUGSGT", "" ], ["<<=:=", "AUGSLE", "" ], ["<<:=", "AUGSLT", "" ], ["~==:=", "AUGSNE", "" ], ["\\", "BACKSLASH", "b" ], ["!", "BANG", "b" ], ["|", "BAR", "b" ], ["^", "CARET", "b" ], ["^:=", "CARETASGN", "b" ], [":", "COLON", "" ], [",", "COMMA", "" ], ["||", "CONCAT", "b" ], ["||:=", "CONCATASGN","" ], ["&", "CONJUNC", "b" ], [".", "DOT", "b" ], ["--", "DIFF", "b" ], ["--:=", "DIFFASGN", "" ], ["===", "EQUIV", "b" ], ["**", "INTER", "b" ], ["**:=", "INTERASGN", "" ], ["{", "LBRACE", "b" ], ["[", "LBRACK", "b" ], ["|||", "LCONCAT", "b" ], ["|||:=", "LCONCATASGN","" ], ["==", "LEXEQ", "b" ], [">>=", "LEXGE", "" ], [">>", "LEXGT", "" ], ["<<=", "LEXLE", "" ], ["<<", "LEXLT", "" ], ["~==", "LEXNE", "b" ], ["(", "LPAREN", "b" ], ["-:", "MCOLON", "" ], ["-", "MINUS", "b" ], ["-:=", "MINUSASGN", "" ], ["%", "MOD", "" ], ["%:=", "MODASGN", "" ], ["~===", "NOTEQUIV", "b" ], ["=", "NUMEQ", "b" ], [">=", "NUMGE", "" ], [">", "NUMGT", "" ], ["<=", "NUMLE", "" ], ["<", "NUMLT", "" ], ["~=", "NUMNE", "b" ], ["+:", "PCOLON", "" ], ["+", "PLUS", "b" ], ["+:=", "PLUSASGN", "" ], ["?", "QMARK", "b" ], ["<-", "REVASSIGN", "" ], ["<->", "REVSWAP", "" ], ["}", "RBRACE", "e" ], ["]", "RBRACK", "e" ], [")", "RPAREN", "e" ], [";", "SEMICOL", "" ], ["?:=", "SCANASGN", "" ], ["/", "SLASH", "b" ], ["/:=", "SLASHASGN", "" ], ["*", "STAR", "b" ], ["*:=", "STARASGN", "" ], [":=:", "SWAP", "" ], ["~", "TILDE", "b" ], ["++", "UNION", "b" ], ["++:=", "UNIONASGN", "" ], ["$(", "LBRACE", "b" ], ["$)", "RBRACE", "e" ], ["$<", "LBRACK", "b" ], ["$>", "RBRACK", "e" ], ["$", "RHSARG", "b" ], ["%$(", "BEGGLOB", "b" ], ["%$)", "ENDGLOB", "e" ], ["%{", "BEGGLOB", "b" ], ["%}", "ENDGLOB", "e" ], ["%%", "NEWSECT", "be"]] # static be_tbl, reserved_tbl reserved_tbl := table() every elem := !reserveds do insert(reserved_tbl, elem[1], elem[2]) be_tbl := table() every elem := !primitives | !reserveds | !operators do { insert(be_tbl, elem[2], elem[3]) } } /getchar := create { line_number := 0 ! ( 1(!stream, line_number +:=1) || "\n" ) } whitespace := ' \t' /next_c := @getchar | { if \stream then return TOK("EOFX") else fail } repeat { case next_c of { "." : { # Could be a real literal *or* a dot operator. Check # following character to see if it's a digit. If so, # it's a real literal. We can only get away with # doing the dot here because it is not a substring of # any longer identifier. If this gets changed, we'll # have to move this code into do_operator(). # last_token := do_dot(getchar) suspend last_token # write(&errout, "next_c == ", image(next_c)) next } "\n" : { # If do_newline fails, it means we're at the end of # the input stream, and we should break out of the # repeat loop. # every last_token := do_newline(getchar, last_token, be_tbl) do suspend last_token if next_c === &null then break next } "\#" : { # Just a comment. Strip it by reading every character # up to the next newline. The global var next_c # should *always* == "\n" when this is done. # do_number_sign(getchar) # write(&errout, "next_c == ", image(next_c)) next } "\"" : { # Suspend as STRINGLIT everything from here up to the # next non-backslashed quotation mark, inclusive # (accounting for the _ line-continuation convention). # last_token := do_quotation_mark(getchar) suspend last_token # write(&errout, "next_c == ", image(next_c)) next } "'" : { # Suspend as CSETLIT everything from here up to the # next non-backslashed apostrophe, inclusive. # last_token := do_apostrophe(getchar) suspend last_token # write(&errout, "next_c == ", image(next_c)) next } &null : stop("iparse_tokens (lexer): unexpected EOF") default : { # If we get to here, we have either whitespace, an # integer or real literal, an identifier or reserved # word (both get handled by do_identifier), or an # operator. The question of which we have can be # determined by checking the first character. # if any(whitespace, next_c) then { # Like all of the TOK forming procedures, # do_whitespace resets next_c. do_whitespace(getchar, whitespace) # don't suspend any tokens next } if any(&digits, next_c) then { last_token := do_digits(getchar) suspend last_token next } if any(&letters ++ '_', next_c) then { last_token := do_identifier(getchar, reserved_tbl) suspend last_token next } # write(&errout, "it's an operator") last_token := do_operator(getchar, operators) suspend last_token next } } } # If stream argument is nonnull, then we are in the top-level # iparse_tokens(). If not, then we are in a recursive call, and # we should not emit all this end-of-file crap. # if \stream then { return TOK("EOFX") } else fail end # # do_dot: coexpression -> TOK record # getchar -> t # # Where getchar is the coexpression that produces the next # character from the input stream and t is a token record whose # sym field contains either "REALLIT" or "DOT". Essentially, # do_dot checks the next char on the input stream to see if it's # an integer. Since the preceding char was a dot, an integer # tips us off that we have a real literal. Otherwise, it's just # a dot operator. Note that do_dot resets next_c for the next # cycle through the main case loop in the calling procedure. # procedure do_dot(getchar) local token # global next_c # write(&errout, "it's a dot") # If dot's followed by a digit, then we have a real literal. # if any(&digits, next_c := @getchar) then { # write(&errout, "dot -> it's a real literal") token := "." || next_c while any(&digits, next_c := @getchar) do token ||:= next_c if token ||:= (next_c == ("e"|"E")) then { while (next_c := @getchar) == "0" while any(&digits, next_c) do { token ||:= next_c next_c = @getchar } } return TOK("REALLIT", token) } # Dot not followed by an integer; so we just have a dot operator, # and not a real literal. # # write(&errout, "dot -> just a plain dot") return TOK("DOT", ".") end # # do_newline: coexpression x TOK record x table -> TOK records # (getchar, last_token, be_tbl) -> Ts (a generator) # # Where getchar is the coexpression that returns the next # character from the input stream, last_token is the last TOK # record suspended by the calling procedure, be_tbl is a table of # tokens and their "beginner/ender" status, and Ts are TOK # records. Note that do_newline resets next_c. Do_newline is a # mess. What it does is check the last token suspended by the # calling procedure to see if it was a beginner or ender. It # then gets the next token by calling iparse_tokens again. If # the next token is a beginner and the last token is an ender, # then we have to suspend a SEMICOL token. In either event, both # the last and next token are suspended. # procedure do_newline(getchar, last_token, be_tbl) local next_token # global next_c # write(&errout, "it's a newline") # Go past any additional newlines. # while next_c == "\n" do { # NL can be the last char in the getchar stream; if it *is*, # then signal that it's time to break out of the repeat loop # in the calling procedure. # next_c := @getchar | { next_c := &null fail } suspend TOK(&null, next_c == "\n") } # If there was a last token (i.e. if a newline wasn't the first # character of significance in the input stream), then check to # see if it was an ender. If so, then check to see if the next # token is a beginner. If so, then suspend a TOK("SEMICOL") # record before suspending the next token. # if find("e", be_tbl[(\last_token).sym]) then { # write(&errout, "calling iparse_tokens via do_newline") # &trace := -1 # First arg to iparse_tokens can be null here. \ (next_token := iparse_tokens(&null, getchar)).sym if \next_token then { # write(&errout, "call of iparse_tokens via do_newline yields ", # ximage(next_token)) if find("b", be_tbl[next_token.sym]) then suspend TOK("SEMICOL", "\n") # # See below. If this were like the real Icon parser, # the following line would be commented out. # else suspend TOK(&null, "\n") return next_token } else { # # If this were a *real* Icon tokenizer, it would not emit # any record here, but would simply fail. Instead, we'll # emit a dummy record with a null sym field. # return TOK(&null, "\n") # &trace := 0 # fail } } # See above. Again, if this were like Icon's own tokenizer, we # would just fail here, and not return any TOK record. # # &trace := 0 return TOK(&null, "\n") # fail end # # do_number_sign: coexpression -> &null # getchar -> # # Where getchar is the coexpression that pops characters off the # main input stream. Sets the global variable next_c. This # procedure simply reads characters until it gets a newline, then # returns with next_c == "\n". Since the starting character was # a number sign, this has the effect of stripping comments. # procedure do_number_sign(getchar) # global next_c # write(&errout, "it's a number sign") while next_c ~== "\n" do { next_c := @getchar } # Return to calling procedure to cycle around again with the new # next_c already set. Next_c should always be "\n" at this point. return end # # do_quotation_mark: coexpression -> TOK record # getchar -> t # # Where getchar is the coexpression that yields another character # from the input stream, and t is a TOK record with "STRINGLIT" # as its sym field. Puts everything upto and including the next # non-backslashed quotation mark into the str field. Handles the # underscore continuation convention. # procedure do_quotation_mark(getchar) local token # global next_c # write(&errout, "it's a string literal") token := "\"" next_c := @getchar repeat { if next_c == "\n" & token[-1] == "_" then { token := token[1:-1] while any('\t ', next_c := @getchar) next } else { if slshupto('"', token ||:= next_c, 2) then { next_c := @getchar # resume outermost (repeat) loop in calling procedure, # with the new (here explicitly set) next_c return TOK("STRINGLIT", token) } next_c := @getchar } } end # # do_apostrophe: coexpression -> TOK record # getchar -> t # # Where getchar is the coexpression that yields another character # from the input stream, and t is a TOK record with "CSETLIT" # as its sym field. Puts everything upto and including the next # non-backslashed apostrope into the str field. # procedure do_apostrophe(getchar) local token # global next_c # write(&errout, "it's a cset literal") token := "'" next_c := @getchar repeat { if next_c == "\n" & token[-1] == "_" then { token := token[1:-1] while any('\t ', next_c := @getchar) next } else { if slshupto("'", token ||:= next_c, 2) then { next_c := @getchar # Return & resume outermost containing loop in calling # procedure w/ new next_c. return TOK("CSETLIT", token) } next_c := @getchar } } end # # do_digits: coexpression -> TOK record # getchar -> t # # Where getchar is the coexpression that produces the next char # on the input stream, and where t is a TOK record containing # either "REALLIT" or "INTLIT" in its sym field, and the text of # the numeric literal in its str field. # procedure do_digits(getchar) local token, tok_record, extras, digits, over # global next_c # For bases > 16 extras := "AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuVvWwXxYyZz" # Assume integer literal until proven otherwise.... tok_record := TOK("INTLIT") # write(&errout, "it's an integer or real literal") token := ("0" ~== next_c) | "" while any(&digits, next_c := @getchar) do token ||:= next_c if token ||:= (next_c == ("R"|"r")) then { digits := &digits if over := ((10 < token[1:-1]) - 10) * 2 then digits ++:= extras[1:over+1] | extras next_c := @getchar if next_c == "-" then { token ||:= next_c next_c := @getchar } while any(digits, next_c) do { token ||:= next_c next_c := @getchar } } else { if token ||:= (next_c == ".") then { while any(&digits, next_c := @getchar) do token ||:= next_c tok_record := TOK("REALLIT") } if token ||:= (next_c == ("e"|"E")) then { next_c := @getchar if next_c == "-" then { token ||:= next_c next_c := @getchar } while any(&digits, next_c) do { token ||:= next_c next_c := @getchar } tok_record := TOK("REALLIT") } } tok_record.str := ("" ~== token) | "0" return tok_record end # # do_whitespace: coexpression x cset -> &null # getchar x whitespace -> &null # # Where getchar is the coexpression producing the next char on # the input stream. Do_whitespace just repeats until it finds a # non-whitespace character, whitespace being defined as # membership of a given character in the whitespace argument (a # cset). # procedure do_whitespace(getchar, whitespace) # write(&errout, "it's junk") while any(whitespace, next_c) do next_c := @getchar return end # # do_identifier: coexpression x table -> TOK record # (getchar, reserved_tbl) -> t # # Where getchar is the coexpression that pops off characters from # the input stream, reserved_tbl is a table of reserved words # (keys = the string values, values = the names qua symbols in # the grammar), and t is a TOK record containing all subsequent # letters, digits, or underscores after next_c (which must be a # letter or underscore). Note that next_c is global and gets # reset by do_identifier. # procedure do_identifier(getchar, reserved_tbl) local token # global next_c # write(&errout, "it's an indentifier") token := next_c while any(&letters ++ &digits ++ '_', next_c := @getchar) do token ||:= next_c return TOK(\reserved_tbl[token], token) | TOK("IDENT", token) end # # do_operator: coexpression x list -> TOK record # (getchar, operators) -> t # # Where getchar is the coexpression that produces the next # character on the input stream, operators is the operator list, # and where t is a TOK record describing the operator just # scanned. Calls recognop, which creates a DFSA to recognize # valid Icon operators. Arg2 (operators) is the list of lists # containing valid Icon operator string values and names (see # above). # procedure do_operator(getchar, operators) local token, elem token := next_c # Go until recognop fails. while elem := recognop(operators, token, 1) do token ||:= (next_c := @getchar) # write(&errout, ximage(elem)) if *\elem = 1 then return TOK(elem[1][2], elem[1][1]) else fail end record dfstn_state(b, e, tbl) record start_state(b, e, tbl, master_list) # # recognop: list x string x integer -> list # (l, s, i) -> l2 # # Where l is the list of lists created by the calling procedure # (each element contains a token string value, name, and # beginner/ender string), where s is a string possibly # corresponding to a token in the list, where i is the position in # the elements of l where the operator string values are recorded, # and where l2 is a list of elements from l that contain operators # for which string s is an exact match. Fails if there are no # operators that s is a prefix of, but returns an empty list if # there just aren't any that happen to match exactly. # # What this does is let the calling procedure just keep adding # characters to s until recognop fails, then check the last list # it returned to see if it is of length 1. If it is, then it # contains list with the vital stats for the operator last # recognized. If it is of length 0, then string s did not # contain any recognizable operator. # procedure recognop(l, s, i) local current_state, master_list, c, result, j static dfstn_table initial dfstn_table := table() /i := 1 # See if we've created an automaton for l already. /dfstn_table[l] := start_state(1, *l, &null, &null) & { dfstn_table[l].master_list := sortf(l, i) } current_state := dfstn_table[l] # Save master_list, as current_state will change later on. master_list := current_state.master_list s ? { while c := move(1) do { # Null means that this part of the automaton isn't # complete. # if /current_state.tbl then create_arcs(master_list, i, current_state, &pos) # If the table has been clobbered, then there are no arcs # leading out of the current state. Fail. # if current_state.tbl === 0 then fail # write(&errout, "c = ", image(c)) # write(&errout, "table for current state = ", # ximage(current_state.tbl)) # If we get to here, the current state has arcs leading # out of it. See if c is one of them. If so, make the # node to which arc c is connected the current state. # Otherwise fail. # current_state := \current_state.tbl[c] | fail } } # Return possible completions. # result := list() every j := current_state.b to current_state.e do { if *master_list[j][i] = *s then put(result, master_list[j]) } # return empty list if nothing the right length is found return result end # # create_arcs: fill out a table of arcs leading out of the current # state, and place that table in the tbl field for # current_state # procedure create_arcs(master_list, field, current_state, POS) local elem, i, first_char, old_first_char current_state.tbl := table() old_first_char := "" every elem := master_list[i := current_state.b to current_state.e][field] do { # Get the first character for the current position (note that # we're one character behind the calling routine; hence # POS-1). # first_char := elem[POS-1] | next # If we have a new first character, create a new arc out of # the current state. # if first_char ~== old_first_char then { # Store the start position for the current character. current_state.tbl[first_char] := dfstn_state(i) # Store the end position for the old character. (\current_state.tbl[old_first_char]).e := i-1 old_first_char := first_char } } (\current_state.tbl[old_first_char]).e := i # Clobber table with 0 if no arcs were added. current_state.tbl := (*current_state.tbl = 0) return current_state end -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Wed Jul 28 20:57:34 1993 Received: by cheltenham.cs.arizona.edu; Mon, 2 Aug 1993 04:57:09 MST Date: 28 Jul 93 20:57:34 GMT From: pipex!uknet!cix.compulink.co.uk!pmoore@uunet.uu.net (Paul Moore) Organization: Compulink Information eXchange Subject: Icon for MVS Message-Id: Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu In the Icon newsletter, an implementation of Icon for MVS is shown ($30 for a mag tape of the complete system). Unfortunately, it is not available on the FTP site (cs.arizona.edu). For various reasons, I am unable to load to our MVS system at present from magnetic tape [:-(] although I can transfer files from FTP. Is the MVS Icon available in ready-to-execute form (ie, no compiler needed) from any FTP site, and if so, where? Thanks in advance, Paul Moore (pmoore@cix.compulink.co.uk) From icon-group-sender Thu Aug 19 15:11:07 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Sun, 22 Aug 1993 14:41:45 MST Received: by owl.cs.arizona.edu; Sun, 22 Aug 1993 14:41:44 MST Date: 19 Aug 93 15:11:07 GMT From: agate!howland.reston.ans.net!vixen.cso.uiuc.edu!uwm.edu!linac!uchinews!raistlin!imcc.cdl.cdc.com!gjones@ucbvax.Berkeley.EDU (Glenn Jones) Organization: Control Data Subject: Icon debugger ??? Message-Id: Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Hi all, This is my first posting to this group. I am looking for any tools to help with interactive debugging of icon programs. I am running icon on a MIPS machine. Any information appreciated. Regards Glenn. -- /-----------------------------------------------------------------\ | Glenn Jones | Internet: gjones@cdl.cdc.com | | Control Data Ltd | Offices: 081-848-1919 x3041 | | 3 Roundwood Av, Stockley Park | : 0242-243457 | | Uxbridge, Middlesex. | Fax :081-848-3133 | | UB11 1AG. | Home : | | England. | Car : | \-----------------------------------------------------------------/ From icon-group-sender Wed Aug 18 15:41:03 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Sun, 22 Aug 1993 14:42:32 MST Received: by owl.cs.arizona.edu; Sun, 22 Aug 1993 14:42:31 MST Date: 18 Aug 93 15:41:03 GMT From: pa.dec.com!open.ac.uk!Bugtales@decwrl.dec.com (Marc Eisenstadt) Subject: 'MY HAIRIEST BUG' TALES: REPEATED REQUEST Message-Id: <9308181541.AA15611@watson.open.ac.uk> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu SUMMARY: Collecting debugging stories for analysis+archive. Please send yours! We are collecting anecdotes describing memorable debugging experiences, with the aim of analysing them and building an archive to assist programmers in the future. We will gratefully accept any stories describing very thorny software bugs, ideally (but not exclusively) involving large software projects and expert programmers. A brief stream-of-consciousness reply right now would be much better than a detailed story that becomes too time-consuming for you to finish. We can get back to you with further questions if necessary. Thanks. That's it! Next are OPTIONAL headings & FTP/email ways to access our study. --------------------------------------------------------------------------- SUGGESTED OPTIONAL HEADINGS to facilitate later analysis & retrieval are supplied below. Please ignore these if they stifle your motivation, otherwise copy/paste :HEADING: labels into your reply. 1-liners (except STORY) are ideal. :DISTRIBUTION: UNRESTRICTED | anyBBS | Internet-only | private :ANONYMITY: keep-author-anonymous | use-name-only | use-name-&-email :EXPERIENCE: e.g. (at time of incident) 7 years industrial C programmer :HARDWARE: e.g. 486 :OS: e.g. DOS 5 + Windows 3.1 :LANGUAGE: e.g. M'Soft Visual C++ :LIBRARIES: e.g. Microsoft Foundation Class :TASK: e.g. writing disk-cacheing software :SYMPTOM: e.g. machine crashed after 40,000 iterations :HOW-NOTICED: e.g. end-user reported it | obvious | Q.A. spotted it | etc. :WHY-HARD: (one or more of...) intermittent | inconsistent | infrequent | too-many-degrees-of-freedom | cause-far-from-effect | bug-consumed-evidence | Heisenbug-ran-OK-with-debugger | tedious-to-replicate | context-precluded-debugger-usage | unstructured-code | thought--was- | misdirected-blame | faulty-assumption | :HOW-SOLVED: (one or more of...) single-step | wrap-in-profiling-code | print-statements | dump-data-study-diffs | conditional-breaks | special-tool | gestation-meditation | explain-to-friend | expert-advice | controlled-experiment | :ROOT-CAUSE: (one or more of...) memory-clobbered | fault-of-vendor | faulty-design-logic | bad-init-or-type-decl | wrong-var-or-op | lexical-or-parsing-or-typo | language-semantics-misunderstood | subtle-end-user-behavior | still-unsolved | :HEADLINE: e.g. MSC disk-cache crash after 40K steps, array index err* :STORY: :MORAL: e.g. don't use pointers without comments *The :HEADLINE: is a one-line overview of the story which will be CRUCIAL for helping others pick it out from among thousands listed in a directory, and therefore should concisely convey the key gist of the story. The categories for :WHY-HARD:, :HOW-SOLVED:, and :ROOT-CAUSE: have proved effective in the past, but they are just there to jog your memory. Your own words (or a combination of the suggested categories plus your own words) may be best. DATA/ANALYSES/MOTIVATION VIA FTP OR EMAIL: If you are interested in data from the previous 'trawls', or our conclusions drawn from them, or a detailed discussion of the motivation for this study, the relevant documents can be obtained by anonymous FTP from hcrl.open.ac.uk (in the directory /pub/bugtales). We will also be setting up an email list-server facility to deal with correspondence. In the meantime, comments, suggestions, and requests for emailed publications can be directed to M.Eisenstadt@open.ac.uk. Stories should be sent to Bugtales@open.ac.uk. Incidentally, since we introduced the 'suggested headings' (e.g. :SYMTPOM:, :ROOT-CAUSE:, etc.) most of the respondents have in fact been using them, which is a great help to us. Many thanks for your time and interest! Finally, thanks to Dan LaLiberte for suggesting the :HOW-NOTICED: category, and to Simon Masterton for assisting with data collection and analysis. -Marc Eisenstadt (Personal email: M.Eisenstadt@open.ac.uk) _/ _/ _/_/_/_/ _/_/_/_/ _/ Human Cognition Research Lab _/ _/ _/ _/ _/ _/ The Open University _/_/_/_/ _/ _/_/_/_/ _/ Milton Keynes MK7 6AA, U.K. _/ _/ _/ _/ _/ _/ Tel: +44 908 65-3800 Fax: -3169 _/ _/ _/_/_/_/ _/ _/ _/_/_/_/ Internet: Bugtales@open.ac.uk From icon-group-sender Mon Aug 23 22:04:14 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Tue, 24 Aug 1993 07:41:52 MST Received: by owl.cs.arizona.edu; Tue, 24 Aug 1993 07:41:51 MST Date: Mon, 23 Aug 93 22:04:14 EDT From: Paul_Abrahams@MTS.cc.Wayne.edu To: icon-group@cs.arizona.edu Message-Id: <727590@MTS.cc.Wayne.edu> Subject: Help!! OS/2 version of Icon 8.10 Status: RO Errors-To: icon-group-errors@cs.arizona.edu I'm running version 8.10 of Icon under OS/2, and whenever I interrupt an executing program (and at other times also), I get a message, "Message file not found". I've experienced the same problem with version 8.8. I've asked the folks at icon-project about this but they don't know anything about it and the person who did the OS/2 port is not in communication with them. So I'm sending this message to the general Icon community in the hope that someone can tell me (a) what file Icon is looking for, and (b) where I should put that file so that Icon can find it. Paul Abrahams reply-to: abrahams@acm.org From icon-group-sender Thu Aug 26 08:13:57 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Thu, 26 Aug 1993 08:13:57 MST Received: by owl.cs.arizona.edu; Thu, 26 Aug 1993 08:13:56 MST Date: Wed, 25 Aug 93 13:44:48 HST From: Phil Bralich Message-Id: <9308252344.AA04358@uhunix.uhcc.Hawaii.Edu> To: icon-group@cs.arizona.edu Subject: ICON and syntax Status: R Errors-To: icon-group-errors@cs.arizona.edu I would like to speak to anyone who is using ICON for any programming involving parsing or translating of natural languages. I would also like to speak to anyone who is interested in working on a parser for English in ICON. Phil Bralich University of Hawaii bralich@uhunix.uhccux.Hawaii.edu From icon-group-sender Fri Aug 27 08:57:24 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Fri, 27 Aug 1993 08:57:24 MST Received: by owl.cs.arizona.edu; Fri, 27 Aug 1993 08:57:23 MST Via: uk.ac.edinburgh.festival; Fri, 27 Aug 1993 11:39:47 +0100 Date: 27 Aug 93 11:39:27 BST From: R J Hare Subject: Pocket PC To: icon-group@cs.arizona.edu Reply-To: r.j.hare@edinburgh.ac.uk Organisation: Edinburgh University Computing Service Message-Id: <9308271139.aa20445@uk.ac.ed.festival> Status: R Errors-To: icon-group-errors@cs.arizona.edu Hi, I'm after a bit of advice which readers of the list may be able to provide. Does anyone have any experience of running Icon on Palmtop PCs? I'm thinking of buying one of these beasts. The one I have in mind is the Sharp-PC3000 which is advertised as having a 10MHz 80C88A processor, 1Mb RAM and 1Mb ROM. I guess this machine would be pretty slow, but is it big enough to run Icon in any 'usable' sense? I'm a bit vague about PC's because even though I have one on my desk, I use it 99% of the time as an X-terminal to connect to our network where I use Icon on a Sun4 & Sequent. If this thing is usable, it will be the ideal platform to run my yacht racing results program on... Thanks. Roger Hare. From icon-group-sender Fri Aug 27 17:41:35 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Sat, 28 Aug 1993 17:21:11 MST Received: by owl.cs.arizona.edu; Sat, 28 Aug 1993 17:21:09 MST Date: 27 Aug 93 17:41:35 GMT From: agate!spool.mu.edu!bloom-beacon.mit.edu!linus!progress!neil@ucbvax.Berkeley.EDU (Neil Galarneau) Organization: Progress Software Corp. Subject: Xicon for MS-Windows? Message-Id: <1993Aug27.174135.15731@progress.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Is there an Xicon for ms-windows? What is its status? Thanks, Neil From icon-group-sender Sat Aug 28 13:56:52 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Sat, 28 Aug 1993 17:21:55 MST Received: by owl.cs.arizona.edu; Sat, 28 Aug 1993 17:21:54 MST Date: 28 Aug 93 13:56:52 GMT From: sdd.hp.com!portal!cup.portal.com!Eric-Amick@hplabs.hpl.hp.com (Richard E Amick) Organization: The Portal System (TM) Subject: Re: system() function Message-Id: <89125@cup.portal.com> References: <1993Aug28.000650.682@jcnpc.cmhnet.org> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu > I have a 286 running under dos 3.3. I use the system() function >to issue the VOL command to dos to see the volume label of the disk >in drive A:. System() returns the dos exit code and not the response >returned by the VOL command. Therefore x := system("Vol") does not >capture the volume label as returned by Vol but rather captures 0, >which is the exit code. > Is there a way under ICON 8.0 to capture the volume label returned >by the dos Vol command as a string? If so, how? The key is to remember that any valid command line can be fed to system(); try something like system("vol >somefile") then open and read "somefile". You can figure out the rest, I'm sure. From icon-group-sender Sat Aug 28 19:59:16 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Sat, 28 Aug 1993 20:45:52 MST Received: by owl.cs.arizona.edu; Sat, 28 Aug 1993 20:45:51 MST Date: Sat, 28 Aug 93 19:59:16 CDT From: jeffery@ringer.cs.utsa.edu (Clinton L. Jeffery) Message-Id: <9308290059.AA04795@ringer.cs.utsa.edu.sunset> To: icon-group@cs.arizona.edu In-Reply-To: (Neil Galarneau's message of 27 Aug 93 17:41:35 GMT <1993Aug27.174135.15731@progress.com> Subject: Xicon for MS-Windows? Status: R Errors-To: icon-group-errors@cs.arizona.edu Neil Galarneau asks: Is there an Xicon for ms-windows? What is its status? There is no X-Icon for MS Windows at present. X-Icon currently runs under various releases of X Windows and OS/2 2.X. I am working on a version of X-Icon for MS Windows; it is initially being written for Windows NT and should also run under Windows 3.1 on 386 platforms using the Win32s libraries. This software will not be ready until some time in 1994. There may be others working on an MS Windows version of X-Icon; I will let them speak for themselves. I'd be interested in hearing from such persons. Clint Jeffery, jeffery@ringer.cs.utsa.edu Division of Math and Computer Science The University of Texas at San Antonio From icon-group-sender Mon Aug 30 03:13:31 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Mon, 30 Aug 1993 07:41:14 MST Received: by owl.cs.arizona.edu; Mon, 30 Aug 1993 07:41:13 MST Date: 30 Aug 93 03:13:31 GMT From: agate!howland.reston.ans.net!darwin.sura.net!sgiblab!wetware!indetech!pacbell!boo!seer!fxg@ucbvax.Berkeley.EDU (Francis X. Guidry) Organization: Brad Lanam, Walnut Creek, CA Subject: Re: system() function Message-Id: References: <1993Aug28.000650.682@jcnpc.cmhnet.org> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu In article <1993Aug28.000650.682@jcnpc.cmhnet.org> jms@jcnpc.cmhnet.org (John M. Salimbene) writes: > I have a 286 running under dos 3.3. I use the system() function >to issue the VOL command to dos to see the volume label of the disk >in drive A:. System() returns the dos exit code and not the response >returned by the VOL command. Therefore x := system("Vol") does not >capture the volume label as returned by Vol but rather captures 0, >which is the exit code. > Is there a way under ICON 8.0 to capture the volume label returned >by the dos Vol command as a string? If so, how? Redirect the output of the vol command to a file, then read the file. system("vol >$$$.tmp") f := open("$$$.tmp") x := !f system("del $$$.tmp") Actually, you'll have to do a bit of scanning to isolate just the volume label, but this should give you the idea. Fran From icon-group-sender Thu Sep 2 20:37:29 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Thu, 2 Sep 1993 20:37:29 MST Received: by owl.cs.arizona.edu; Thu, 2 Sep 1993 20:37:28 MST Via: uk.ac.manchester.computer-science; Thu, 2 Sep 1993 23:25:24 +0100 From: Steve Holden Date: Thu, 2 Sep 93 22:18:50 BST Message-Id: <290.9309022118@desktop.desktop.co.uk> To: icon-group@cs.arizona.edu Subject: Solaris 2.2 on SPARC Status: R Errors-To: icon-group-errors@cs.arizona.edu I wonder if someone could enlighten me as to the current status of Icon on this platform - sorry, I don't currently have Internet access so I can't FTP to find out. regards Steve From icon-group-sender Fri Sep 3 13:28:04 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Fri, 3 Sep 1993 13:29:15 MST Received: by owl.cs.arizona.edu; Fri, 3 Sep 1993 13:29:14 MST Date: Fri, 3 Sep 1993 13:28:04 MST From: "Gregg Townsend" Message-Id: <199309032028.AA08262@owl.cs.arizona.edu> To: icon-group Subject: Re: Icon on Solaris 2.2 Status: R Errors-To: icon-group-errors@cs.arizona.edu Icon was successfully built and tested on Solaris 2.1 and the binaries, at least, work just fine under 2.2. I've had no occasion to rebuild the source under 2.2 but am not aware of any problems. We have an FTP-by-mail server; for details, send a message saying "help" to ftpmail@cs.arizona.edu. You'll want to get the feile /icon/binaries/unix/sun4_solaris/solaris.tar.Z. Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 602 621 4325 gmt@cs.arizona.edu 110 57 16 W / 32 13 45 N / +758m From icon-group-sender Mon Sep 6 12:57:15 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Mon, 6 Sep 1993 12:57:15 MST Received: by owl.cs.arizona.edu; Mon, 6 Sep 1993 12:57:13 MST Via: uk.ac.edinburgh.festival; Mon, 6 Sep 1993 08:28:53 +0100 Date: 06 Sep 93 08:28:46 BST From: R J Hare Subject: returning results from procedure To: icon-group@cs.arizona.edu Reply-To: r.j.hare@edinburgh.ac.uk Organisation: Edinburgh University Computing Service Message-Id: <9309060828.aa21320@uk.ac.ed.festival> Status: R Errors-To: icon-group-errors@cs.arizona.edu I've been using Icon for seberal years now, but recently I stumbled across a 'problem' for the fist time - I wanted to return more than one result from a procedure (yup - strange to relate, after several years I had never needed to do this before). What I want to know is "what is the 'best' way to return several results from a procedure?'. One obvious way to do it is to use a list: procedure myproc . list_of_results:=[] . . list_of_results[1]:=... list_of_results[2]:=... . . return list_of_results end but I guess that one could use a record. Any thoughts on which is best? Thanks. Roger Hare From icon-group-sender Tue Sep 7 00:30:31 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Tue, 7 Sep 1993 08:22:43 MST Received: by owl.cs.arizona.edu; Tue, 7 Sep 1993 08:22:42 MST Date: Tue, 7 Sep 93 00:30:31 -0700 From: "Nevin Jerome Liber" Message-Id: <9309070730.AA18987@caslon.CS.Arizona.EDU> To: icon-group@cs.arizona.edu Subject: Re: return results from procedure Status: R Errors-To: icon-group-errors@cs.arizona.edu rjhare@festival.ed.ac.uk (Roger Hare) writes: > I've been using Icon for seberal years now, but recently I stumbled across a > 'problem' for the fist time - I wanted to return more than one result from a > procedure (yup - strange to relate, after several years I had never needed to > do this before). > What I want to know is "what is the 'best' way to return several results from > a procedure?'. What I find most idiomatic for returning multiple results from a procedure is to use generators. The called routine would look like: procedure MyProcedure() ... suspend xResult1 ... suspend xResult2 ... ... suspend xResultN ... end And the caller would look like: ... every xElement := MyProcedure() do { ProcessElement(xElement) } ... This approach is space-efficient (if the data is being used in a FIFO order, only one element has to be in existence at a given time) and very flexible. The caller, and not the callee can determine what type of data structure to keep the elements in (unlike in more traditional languages like C and Pascal). For example, if I needed to build both an ordered list and a set, I could write the caller like: LList := list() SSet := set() every xElement := MyProcedure() do { put(LList, xElement) insert(SSet, xElement) } ___ Nevin ":-)" Liber nevin@cs.arizona.edu (602) 293-2799 From icon-group-sender Tue Sep 7 09:30:57 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Tue, 7 Sep 1993 08:23:43 MST Received: by owl.cs.arizona.edu; Tue, 7 Sep 1993 08:23:42 MST Message-Id: <9309071457.AA15180@relay2.UU.NET> Subject: Re: return results To: uunet!cs.arizona.edu!icon-group@uunet.uu.net (Icon News Group) Date: Tue, 7 Sep 93 9:30:57 CDT From: Jerry Nowlin X-Mailer: ELM [version 2.3 PL11] Status: R Errors-To: icon-group-errors@cs.arizona.edu > I've been using Icon for seberal years now, but recently I stumbled across a > 'problem' for the fist time - I wanted to return more than one result from a > procedure (yup - strange to relate, after several years I had never needed to > do this before). > > What I want to know is "what is the 'best' way to return several results from > a procedure?'. One obvious way to do it is to use a list: > > procedure myproc > . > list_of_results:=[] > . > . > list_of_results[1]:=... > list_of_results[2]:=... > . > . > return list_of_results > end > > but I guess that one could use a record. > > Any thoughts on which is best? > > Thanks. > > Roger Hare It sounds like you should turn your procedure into a generator. That's the iconish (sic) way to return more than one result from a procedure. When the list of results is exhausted the procedure fails. Jerry Nowlin uunet!isidev!nowlin (uucp) isidev!nowlin@uunet.uu.net (internet) From icon-group-sender Tue Sep 7 10:51:47 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Tue, 7 Sep 1993 09:02:42 MST Received: by owl.cs.arizona.edu; Tue, 7 Sep 1993 09:02:41 MST Date: Tue, 07 Sep 1993 10:51:47 -0600 (CST) From: Chris Tenaglia - 257-8765 Subject: Re: return results To: icon-group@cs.arizona.edu Message-Id: <01H2NWSUY7428WWOAL@mis.mcw.edu> Organization: Medical College of Wisconsin (Milwaukee, WI) X-Vms-To: IN%"icon-group@cs.arizona.edu" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Status: R Errors-To: icon-group-errors@cs.arizona.edu I have occasions to use this too. I think it depends on whether the results are part of a series. Then the 'suspend' approach is better suited. I have shied away from records, and return lists in most other cases. I think it may also be handy to return a table. Then you can have random access to the multiple results by some key. procedure called() result := table("n/a") result["value"] := operation1() result["fudge"] := operation2() result["guess"] := operation3() result["speci"] := operation4() result["quant"] := 6 result["keys"] := "value fudge guess spec quant keys" return result end ... query := called() Then query["keys"] returns the names of the keys. Well a key(query) could cycle between them too. Also query["quant"] returns the number keys. I suppose you caould pack all sorts of meta-information into something that returns a table. Mostly I like the freedom to use all, some, one or none of the results in any random order. I don't use this yet, but this stream of inspired the idea (maybe in parallel with many others. Chris Tenaglia (System Manager) | "The past explained, Medical College of Wisconsin | the future fortold, 8701 W. Watertown Plank Rd. | the present largely appologized for." Milwaukee, WI 53226 | Organon to The Doctor (414)257-8765 | tenaglia@mis.mcw.edu From icon-group-sender Sun Sep 12 01:25:01 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Sat, 11 Sep 1993 19:54:05 MST Received: by owl.cs.arizona.edu; Sat, 11 Sep 1993 19:54:04 MST Date: 12 Sep 93 01:25:01 GMT From: haven.umd.edu!cville-srv.wam.umd.edu!michele@uunet.uu.net (thirtysomething) Organization: University of Maryland, College Park Subject: ICON compilers for Intel platform? Message-Id: <26ttpd$2nq@cville-srv.wam.umd.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu I am looking for ICON on any/all of the following: MS DOS 6.0 MS Windows 3.1 MS Windows NT 3.1 I am running a 486 w/16Mb RAM and hundreds of megabytes of disk free. From icon-group-sender Sun Sep 12 14:42:40 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Sun, 12 Sep 1993 09:55:10 MST Received: by owl.cs.arizona.edu; Sun, 12 Sep 1993 09:55:09 MST Date: 12 Sep 93 14:42:40 GMT From: wraeththu.cs.colorado.edu!tchrist@boulder.colorado.edu (Tom Christiansen) Organization: Usenix Association Office, Berkeley CA Subject: Call for Participation: USENIX SYMPOSIUM ON VERY HIGH LEVEL LANGUAGES Message-Id: <1993Sep12.144240.23999@colorado.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu USENIX SYMPOSIUM ON VERY HIGH LEVEL LANGUAGES (VHLL) October 26-28, 1994 El Dorado Hotel Santa Fe, New Mexico DATES FOR REFEREED PAPER SUBMISSIONS: Extended Abstracts Due: June 30, 1994 Notifications to Authors: July 27, 1994 Final Papers Due: Sept 12, 1994 REGISTRATION MATERIALS AVAILABLE: August, 1994 PROGRAM COMMITTEE Program Chair: Tom Christiansen, Consultant Stephen C. Johnson, Melismatic Software Brian Kernighan, AT&T Bell Laboratories John Ousterhout, University of California, Berkeley Henry Spencer, University of Toronto Using very high level languages (VHLLs), programmers can assemble entire applications from large building blocks in just a small fraction of the time required if conventional programming strategies were used. These languages allow programmers to take advantage of increasingly available hardware cycles, trading cheap machine time for costly programmer time. Thus, VHLLs offer one of the most promising approaches toward radically improving programmer productivity. UNIX has long supported very high level languages: consider awk and the various shells. Often programmers create what are essentially new little languages whenever a problem appears of sufficient complexity to merit a higher level programming interface -- consider sendmail.cf. In recent years many UNIX programmers have been turning to VHLLs for both rapid prototypes and complete applications. They take advantage of these languages' higher level of abstraction to complete projects more rapidly and more easily than they could have using lower-level languages. Some VHLLs such as TCL, Perl, Icon, and REXX have gained widespread use and popularity. Many others never see the public light. Some of these languages are special purpose, addressing a limited-problem domain (such as graphics, text processing, or mathematical modeling) using powerful primitives created for that specific problem. Other VHLLs are more general purpose in nature, but still much higher level than most traditional compiled languages. Some are stand-alone languages, while others are designed to be embedded in other programs. Many are interpreted, although some are compiled to native machine code; a few occupy a gap between both worlds. SYMPOSIUM SCOPE AND FORMAT The USENIX Symposium on Very High Level Languages will spotlight these languages and their usefulness in leveraging certain kinds of tasks. The Symposium will introduce participants to concepts and approaches they haven't examined yet, and publish original work in these areas. Programmers will learn about the relative strengths and weaknesses and extract the key concepts that run through the various languages presented. The USENIX Symposium on Very High Level Languages will run three days: * Wednesday, October 26, will feature hour-long overviews by invited speakers of some of the more popular VHLLs in use today, such as TCL, Perl, Icon, and REXX. * Thursday and Friday, October 27-28, will consist of refereed papers, tutorial-style invited talks on related topics, and panel discussions. * Birds-of-a-Feather sessions will be held Wednesday and Thursday evenings, and a Reception will be held Thursday evening. Papers on brand-new languages, on existing languages about which little or nothing has been published, on applications that use these languages in creative fashions not yet seen, and on experiences at extending existing languages (for example, adding windowing capabilities to awk) are all welcome. Papers should address designing, building, testing, debugging, and measuring the performance and usability of these languages, as well as reference and compare related work in the area. Mention both advantages and disadvantages of the approach selected. For applications using these languages, compare and contrast the design, development, and support effort that were required with this approach versus one using a lower-level language. Good papers will be of interest to people who use other VHLLs than the one described in the paper. For example, a paper describing a system built in a particular language will be much more interesting if it highlights some important feature of the language or problems with the language, or some issue relevant to VHLLs in general. HOW TO SUBMIT TO THE SYMPOSIUM: Persons interested in participating in panel discussions or organizing Birds-of-a-Feather sessions should contact the program chair as indicated below. Submissions of papers to be presented at the Symposium and published in the Symposium Proceedings must be in the form of an extended abstract. The extended abstract should be1500-2500 words (3-5 pages) and must be received by June 30, 1994. (If you do send a full paper, you must also include an extended abstract for evaluation.) The extended abstract should represent your paper in short form. Its purpose is to convince the program committee that a good paper and presentation will result. You should show that you are addressing an interesting problem, have surveyed existing solutions, have devised an innovative, original solution, and have drawn appropriate conclusions about what has been learned. All submissions should indicate the electronic mail address and telephone number of a principal contact. Authors will be notified of acceptance by July 27, 1994, and will be provided with guidelines for preparing camera-ready copy of the final paper. The final paper must be received no later than September 12, 1994. Note that the USENIX conference, like most conferences and journals, considers it unethical to submit the same paper simultaneously to more than one conference or publication or to submit a paper that has been or will be published elsewhere. Please submit your extended abstracts to the program chair as follows. EMAILED SUBMISSIONS (PREFERRED): must be in ASCII, troff (with the -me macro set or raw troff preferred), or Postscript form; send to tchrist@usenix.org HARD COPY SUBMISSIONS: * via FAX to +1 (303) 442-7177 (Please refer to Tom Christiansen) * via postal mail, please submit 6 paper copies to: Tom Christiansen USENIX VHLL Symposium 2227 Canyon Blvd, #262 Boulder CO 80302 FOR PROGRAM AND REGISTRATION INFORMATION: Materials containing full details of the symposium program, registration fees and forms, and hotel discount and reservation information will be mailed and posted to the net in August 1994. If you wish to receive these materials, please contact: USENIX Conference Office 22672 Lambert Street, Suite 613 Lake Forest, CA USA 92630 +1 (714) 588-8649; FAX: +1 (714) 588-9706 Internet: conference@usenix.org -- Tom Christiansen tchrist@cs.colorado.edu 303-444-3212 From icon-group-sender Sun Sep 12 19:15:12 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Mon, 13 Sep 1993 07:33:29 MST Received: by owl.cs.arizona.edu; Mon, 13 Sep 1993 07:33:28 MST Date: 12 Sep 93 19:15:12 GMT From: ucivax!gateway@ucbvax.Berkeley.EDU (Owen O'Malley) Subject: Re: Help on a simple problem. Message-Id: <3441.747861298@porte-de-st-ouen.ics.uci.edu> References: <26qre8INNq0g@dns1.NMSU.Edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu >I have the following program that just computers a number to a certain >power....I also have it written to write the output to a file...my >problem is this...with very large numbers, i get a huge result >which ends up being written as 1 line. Is there a way I could >split the output up so that it is written to numerous lines, 80 chars >per line. Ie: If you asked it to do 2 to the 5000th power you would >get a number that was 15-20 lines long...i need that to be printed >in a file as 15-20 seperate lines, not just one line. The way that I would do it is: # Note: I took the liberty of changing your algorithm so that it # actually computes x^y # Line_Break take a character and prints it out, possibly with a line # break. I choose to make it handle a character, but you could easily # move the ! inside the procedure and pass in an entire string. procedure Line_Break(ch) static posn; initial {posn:=1} if posn > 72 then { write(); posn := 1; } writes(ch); posn +:= 1; end procedure main() write("Please enter a number. ") n := read() write("Please enter another number. ") num:=read() count:=1; every 1 to num do { count *:= n } write() if num = 3 | num % 10 - 3 = 0 & num != 13 then write(n, " to the ", num,"rd power is: ") else if num = 2 | num % 10 - 2 = 0 & num != 12 then write(n, " to the ", num,"nd power is: ") else write(n, " to the ", num, "th power is: ") every Line_Break(!count); write() end From icon-group-sender Sun Sep 12 02:30:21 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Mon, 13 Sep 1993 07:34:10 MST Received: by owl.cs.arizona.edu; Mon, 13 Sep 1993 07:34:09 MST Date: 12 Sep 93 02:30:21 GMT From: yeshua.marcam.com!zip.eecs.umich.edu!caen!kuhub.cc.ukans.edu!parsifal.umkc.edu!UMSLVMA.UMSL.EDU!S965943@uunet.uu.net, Numeral@cs.arizona.edu, Man@cs.arizona.edu Organization: UM-St. Louis Subject: Re: Help on a simple problem. Message-Id: <16C4612E6D.S965943@UMSLVMA.UMSL.EDU> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: RO Errors-To: icon-group-errors@cs.arizona.edu Personally, I'd have it write everything to a temp file, then open the *real* file, read 80 characters, write 80 characters + #13... Then erase the temp file. If disk space is a problem, read all characters into memory, rewrite the file, and let 80 characters out at a time followed by #13... If disk space AND memory is a problem, then you've got me stumped. By the way... If you write 80 characters to the screen followed by a #13, you will end up with a line followed by a blank line followed by a line... Sincerely hoping I've helped, - Roman Numeral Man From icon-group-sender Sun Sep 12 08:19:08 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Mon, 13 Sep 1993 07:34:45 MST Received: by owl.cs.arizona.edu; Mon, 13 Sep 1993 07:34:44 MST Date: 12 Sep 93 08:19:08 GMT From: news-feed-1.peachnet.edu!news-feed-2.peachnet.edu!umn.edu!lynx.unm.edu!dns1.NMSU.Edu!cymorg@gatech.edu (Tanis Half-Elven) Organization: Alternative Collegiate Computing Association Subject: another newbie question (simple) Message-Id: <26um1sINNjvj@dns1.NMSU.Edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: RO Errors-To: icon-group-errors@cs.arizona.edu I have another easy to solve (i hope) problem, that i can't figure out simply because I dont have any documentation nor the money to get the book I so dearly need. I would like to somehow take a string s, and rewrite it, say (for example) as a new string with each letter being the letter following the one in the original word....ie: hello, becomes: ifmmp how would I do this in icon? Thanx, Chris -- **--** Woman don't you know with you i'm born again **--** > < > Chris Fagyal < > Cymorg@acca.nmsu.edu < From icon-group-sender Sun Sep 12 18:09:02 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Mon, 13 Sep 1993 07:35:36 MST Received: by owl.cs.arizona.edu; Mon, 13 Sep 1993 07:35:35 MST Date: 12 Sep 93 18:09:02 GMT From: agate!howland.reston.ans.net!vixen.cso.uiuc.edu!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Subject: Re: another newbie question (simple) Message-Id: <1993Sep12.180902.16530@midway.uchicago.edu> References: <26um1sINNjvj@dns1.NMSU.Edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu cymorg@acca.nmsu.edu (Tanis Half-Elven) writes: >I would like to somehow take a string s, and rewrite it, say, >as a new string with each letter being the letter following >the one in the original word....ie: > >hello, becomes: ifmmp maybe (assuming no &letters, and assuming z wraps around to a): procedure rotate(s) static letters, newbies initial { letters := &ucase || &lcase newbies := &ucase[2:0] || "A" || &lcase[2:0] || "a" } return map(s, letters, newbies) end This is just off the top of my head, and isn't tested. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Mon Sep 13 10:00:24 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Mon, 13 Sep 1993 09:47:15 MST Received: by owl.cs.arizona.edu; Mon, 13 Sep 1993 09:47:14 MST Date: Mon, 13 Sep 1993 10:00:24 -0600 (CST) From: Chris Tenaglia - 257-8765 Subject: Re: newbie question To: icon-group@cs.arizona.edu Message-Id: <01H2W8U4NC428WWTKA@mis.mcw.edu> Organization: Medical College of Wisconsin (Milwaukee, WI) X-Vms-To: IN%"icon-group@cs.arizona.edu" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Status: R Errors-To: icon-group-errors@cs.arizona.edu > From: IN%"news-feed-1.peachnet.edu!news-feed-2.peachnet.edu!umn.edu!lynx.unm.edu!dns1.NMSU.Edu!cymorg@gatech.edu" 13-SEP-1993 09:42:19.58 > To: IN%"icon-group@cs.arizona.edu" > Subj: another newbie question (simple) > I have another easy to solve (i hope) problem, that i can't > figure out simply because I dont have any documentation nor > the money to get the book I so dearly need. I would like > to somehow take a string s, and rewrite it, say (for example) > as a new string with each letter being the letter following > the one in the original word....ie: > hello, becomes: ifmmp > how would I do this in icon? > Thanx, > Chris > -- > **--** Woman don't you know with you i'm born again **--** > > < > > Chris Fagyal < > > Cymorg@acca.nmsu.edu < This can be easily done using the map() expression: # # this rotates the characterset in a string. # input : is the input string # shift : is the amount of rotation (0 < shift 256) # use : newstring := rotn(oldstring,13) # to do ROT13 for example # procedure rotn(input,shift) static transpose initial transpose := string(&cset) || string(&cset) translate := transpose[shift+:256] return map(input,&cset,translate) end map() takes an input string and two mapping strings that must be of equal length. Without the mapping strings specified, it defaults to a convert all strings to lower case. The static and initial make transpose permanent storage and evaluates it only once (the first time). Chris Tenaglia (System Manager) | "The past explained, Medical College of Wisconsin | the future fortold, 8701 W. Watertown Plank Rd. | the present largely appologized for." Milwaukee, WI 53226 | Organon to The Doctor (414)257-8765 | tenaglia@mis.mcw.edu From icon-group-sender Mon Sep 13 14:17:05 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Mon, 13 Sep 1993 09:48:53 MST Received: by owl.cs.arizona.edu; Mon, 13 Sep 1993 09:48:52 MST Date: 13 Sep 93 14:17:05 GMT From: agate!doc.ic.ac.uk!uknet!mcsun!sun4nl!rulway.LeidenUniv.nl!ruls41.LeidenUniv.nl!ruiter@ucbvax.Berkeley.EDU (Jan-Peter de Ruiter) Organization: Leiden University, Netherlands Subject: File Scanning revisited Message-Id: <1993Sep13.141705.21611@rulway.LeidenUniv.nl> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu About a year ago (maybe less) the concept of *file* scanning (as opposed to *string* scanning) was discussed. Since then I have payed attention, and I started realizing that the only reason I sometimes do C++ in text processing is that I have a "sort of file scanner" in C++. [ For those who do not remember: file scanning is just like string scanning, with a file (stream of characters) as &subject. Position 0 would then be end-of-file, for instance. Some problems could arise due to the possible backtracking, so a clever buffering scheme is needed. Also, devices without a seek_backwards possibility would have limited backtracking. ] If Icon would have file scanning, even if somewhat slow, it would be *v*e*r*y* nice. It just keeps nagging in the back of my head, this feeling that it belongs in Icon. For instance, my colleage next door is a C hacker who does all his text processing in C. I tried to 'convert' him to Icon, but he soon stopped because doing Icon he didn't like the line-by-line approach of Icon. So my questions are: 1. Has the implementation of file scanning been discussed in Icon circles? 2. Do other Icon programmers agree that file scanning is a "must"? Greetings, Jan de Ruiter University of Leiden Dept. of Experimental Psychology Netherlands From icon-group-sender Mon Sep 13 15:39:31 1993 Received: from owl.CS.Arizona.EDU by cheltenham.cs.arizona.edu; Mon, 13 Sep 1993 15:01:11 MST Received: by owl.cs.arizona.edu; Mon, 13 Sep 1993 15:01:09 MST Date: 13 Sep 93 15:39:31 GMT From: agate!msuinfo!uchinews!kimbark!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Subject: Re: File Scanning revisited Message-Id: <1993Sep13.153931.27591@midway.uchicago.edu> References: <1993Sep13.141705.21611@rulway.LeidenUniv.nl> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu ruiter@ruls41.LeidenUniv.nl (Jan-Peter de Ruiter) writes: > >1. Has the implementation of file scanning been discussed in Icon circles? >2. Do other Icon programmers agree that file scanning is a "must"? Yes and yes. We had a discussion about it a few months ago. Ken Walker had some ideas. As I recall, the notion of file scanning has been con- sidered a desideratum by the Icon Project itself for a good decade. I doubt if it's high on the priority list at this point, though. My own reason for liking the idea of file scanning is that I would not have to use low-level I/O mechanisms like reads() to perform lexical analy- sis. Right now, Icon has few advantages over C in this area, and many dis- advantages. You can't use string scanning for lexical analysis unless you don't mind restricting yourself to line-oriented file structures or are wil- ling to read in huge chunks of a file as a single string. Other schemes are doubtless possible, but file scanning is the obvious way of making the lexing more amenable to Iconish processing. I can't offer any implementation suggestions, I'm sorry to say, because I no longer understand the implementation sufficiently well to do a decent job of implementing file scanning. I fell behind after 8.0, and haven't had the chance to catch up (I'm more concerned about publishing and doing research in my own field just now...). -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Thu Sep 16 11:27:13 1993 Received: by cheltenham.cs.arizona.edu; Thu, 16 Sep 1993 12:47:25 MST Message-Id: <199309161527.AA22243@optima.CS.Arizona.EDU> From: John Kohl Subject: Reading PS files To: icon-group@cs.arizona.edu Date: Thu, 16 Sep 93 11:27:13 EDT Cc: garl@lhc.nlm.nih.gov X-Mailer: ELM [version 2.3 PL11] Status: R Errors-To: icon-group-errors@cs.arizona.edu We at Palet Software Inc. are developing puzzle games for use under MS Windows. Our first game, Traction, was written using BorlandC. Its 250 k Byte source is more low level than we want to endure again. This was all the more remarkable in that Gary LeTourneau (our chief developer) has muscular dystrophy. He can no longer use standard keyboards or mice. We intend to try XIcon under OS/2 as a prototyping environment for new games. If successful, we will shift over to the Win32s version when available next year. An immediate limitation is XIcon's documentation is in Postscript. We've printed and read this. But Gary needs an online version of the procedure calls for when he is programming. A Postscript reader under OS/2 would be great. Otherwise, we would appreciate an ascii version of the XIcon procedure calls. John Kohl Univ Md University College kohl@socrates.umd.edu From icon-group-sender Thu Sep 9 11:51:42 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Thu, 16 Sep 1993 15:16:38 MST Received: by owl.cs.arizona.edu; Thu, 16 Sep 1993 15:16:37 MST Date: 9 Sep 93 11:51:42 GMT From: psinntp!aztech.ba.md.us!simard@uunet.uu.net (Don Simard) Organization: AzTechnology - Tiny Town, MD Subject: FAQ Message-Id: Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu is there a FAQ for ICON? From icon-group-sender Fri Sep 10 19:11:28 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Fri, 17 Sep 1993 07:46:27 MST Received: by owl.cs.arizona.edu; Fri, 17 Sep 1993 07:46:26 MST Date: 10 Sep 93 19:11:28 GMT From: cis.ohio-state.edu!math.ohio-state.edu!howland.reston.ans.net!vixen.cso.uiuc.edu!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Subject: Re: FAQ Message-Id: <1993Sep10.191128.25703@midway.uchicago.edu> References: Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu >is there a FAQ for ICON? Nope. Not enough traffic to justify it. Just ask away. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Fri Sep 17 09:01:50 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Fri, 17 Sep 1993 09:01:50 MST Received: by owl.cs.arizona.edu; Fri, 17 Sep 1993 09:01:49 MST Via: uk.ac.edinburgh.festival; Fri, 17 Sep 1993 15:58:59 +0100 Date: 17 Sep 93 15:58:50 BST From: R J Hare Subject: Random number seeds To: icon-group@cs.arizona.edu Reply-To: r.j.hare@edinburgh.ac.uk Organisation: Edinburgh University Computing Service Message-Id: <9309171558.aa27306@uk.ac.ed.festival> Status: R Errors-To: icon-group-errors@cs.arizona.edu Er, what's the 'best' (whatever that means) way to seed &random with a start value? I have usually used the numbers from the date-time string, but sometimes note that when doing this I tend to get several random choices from the same part of a large list. thanks Roger Hare. From icon-group-sender Fri Sep 17 11:38:22 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Fri, 17 Sep 1993 12:43:21 MST Received: by owl.cs.arizona.edu; Fri, 17 Sep 1993 12:43:19 MST Date: Fri, 17 Sep 1993 11:38:22 MST From: "Cliff Hathaway" Message-Id: <199309171838.AA26067@javelina.cs.arizona.edu> To: icon-group Subject: help finding similar work (corpus analysis) Status: R Errors-To: icon-group-errors@cs.arizona.edu Anyone out there with any pointers? Thanks. cliff > From: Doug Skuce > Subject: help find similar work > To: icon-project@cs.arizona.edu > I am hoping to use Icon for corpus analysis. I would like to know > if there is anyone using it for any of the following common tasks: > tagging > term extraction > lexicon building > concordancing > or even parsing > > I am fairly familiar with this literature but have never seen a reference > to Icon. SInce it is such a nice language (beats C or Lisp) I wonder > if anyone has used it for such purposes. ANy assistance would be appreciated. > > -- > Thanks from: Doug Skuce | e-mail: doug@csi.uottawa.ca > Department of Computer Science | > University of Ottawa | phone : (613) 564-5418 > Ottawa, K1N 6N5, Canada | fax : (613) 564-9486 From icon-group-sender Fri Sep 17 11:41:57 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Fri, 17 Sep 1993 15:06:13 MST Received: by owl.cs.arizona.edu; Fri, 17 Sep 1993 15:06:11 MST Date: 17 Sep 93 11:41:57 GMT From: taco!inxs.concert.net!rock.concert.net!glv@gatech.edu (Glenn L Vanderburg -- Personal Account) Organization: MCNC Center for Communications -- PUBLIC ACCESS UNIX Subject: Re: ICON on Linux / Solaris Message-Id: <27c7q5$pjd@inxs.concert.net> References: <1993Sep16.154223.29621@nessie.mcc.ac.uk> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu john@nessie.mcc.ac.uk writes: >I have recently compile ICON 8.10 up on out SUN 630MP under SUNOS, >but have had trouble getting it to compile under Solaris on a SS10/52, >and on my 486/33 with Linux. Help!! I had to make one modification to the config files to get icon to compile properly on my Linux system. In the file config/unix/i386_linux/define.h, I removed the line: #define EventMon There might be a better way to get things to work, but EventMon is only used for statistics gathering, so far as I can tell, and everything seems to work fine now. I did not configure my icon system with X support, however. ---glv From icon-group-sender Tue Sep 14 20:42:12 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Mon, 20 Sep 1993 08:40:51 MST Received: by owl.cs.arizona.edu; Mon, 20 Sep 1993 08:40:50 MST Date: 14 Sep 93 20:42:12 GMT From: cis.ohio-state.edu!pacific.mps.ohio-state.edu!math.ohio-state.edu!howland.reston.ans.net!spool.mu.edu!umn.edu!lynx.unm.edu!dns1.NMSU.Edu!cymorg@ucbvax.Berkeley.EDU (Tanis Half-Elven) Organization: Alternative Collegiate Computing Association Subject: Yet another question for the icon experts. Message-Id: <275ab4INNjtd@dns1.NMSU.Edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu I have yet another question for everyone out there, as I continue my quest to learn the language. Given a text file in the format below, how would I access the text file, searching by number, and then when I found that number, print out the information to the next number: ie: 1 info here more info 2 some other info here more info 3 more info etc. etc. etc. 100 last line of info Any and all responses are welcome and very much appreciated and will receive a personal thank you from me :) Thanx, Chris -- **--** Woman don't you know with you i'm born again **--** > < > Chris Fagyal < > Cymorg@acca.nmsu.edu < From icon-group-sender Sun Sep 19 15:25:34 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Mon, 20 Sep 1993 08:39:36 MST Received: by owl.cs.arizona.edu; Mon, 20 Sep 1993 08:39:34 MST Date: Sun, 19 Sep 1993 15:25:34 -0600 (CST) From: Chris Tenaglia - 257-8765 Subject: Banner.Icn To: icon-group@cs.arizona.edu Message-Id: <01H34Y306RUQ8WX3XJ@mis.mcw.edu> Organization: Medical College of Wisconsin (Milwaukee, WI) X-Vms-To: IN%"icon-group@cs.arizona.edu" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Status: R Errors-To: icon-group-errors@cs.arizona.edu I realize that I let Labor Day pass without posting an interesting piece of Icon code. I wrote a handy little code fragment called ibanner. I know icon is mostly in the unix world and unix already has a banner command. But I'm mostly in the DOS and VMS world so I offer this little banner code. It outputs enlarged letters (5x6 matrix) portraite. With a little diddling you can change the scale or font since this is the source. Maybe it can be made to take an input file as a font, and maybe even from xwindows. But this is a simple one. I include a main() procedure that calls it so you can test it and build from there. Enjoy! Chris Tenaglia (System Manager) | "The past explained, Medical College of Wisconsin | the future fortold, 8701 W. Watertown Plank Rd. | the present largely appologized for." Milwaukee, WI 53226 | Organon to The Doctor (414)257-8765 | tenaglia@mis.mcw.edu ######################################################################## procedure main(param) system("cls") every write(!banner(param[1])) end # # a bbbb cccc dddd eeeee fffff gggg h h iii jjj k k l m m # a a b b c d d e f g h h i j k k l mm mm # a a bbbb c d d eee fff g hhhhh i j kk l m m m # aaaaa b b c d d e f g gg h h i j k k l m m # a a b b c d d e f g g h h i j j k k l m m # a a bbbb cccc dddd eeeee f gggg h h iii jj k k lllll m m # # n n ooo pppp qqq rrrr ssss ttttt u u v v w w x x y y zzzzz # nn n o o p p q q r r s t u u v v w w x x y y z # n n n o o pppp q q rrrr sss t u u v v w w w x y z # n nn o o p q q q r r s t u u v v ww ww x x y z # n n o o p q qq r r s t u u v v w w x x y z # n n ooo p qqqq r r ssss t uuu v w w x x y zzzzz # # # 1 222 3333 4 4 55555 666 77777 888 999 00000 # 11 2 2 3 4 4 5 6 7 8 8 9 9 0 0 # 1 2 3333 44444 5555 6666 7 888 9999 0 00 # 1 2 3 4 5 6 6 7 8 8 9 0 0 0 # 1 2 3 4 5 6 6 7 8 8 9 00 0 # 111 22222 3333 4 5555 666 7 888 999 00000 # # # # ??? !! ::: # ? ? !! ::: / # ? !! // ----- # ? !! // ----- # ::: ... // # ? !! ::: ... // # # procedure banner(str) static alphabet initial { alphabet := table("") alphabet["a"] := [" A "," A A ","A A ","AAAAA ","A A ","A A "] alphabet["b"] := ["BBBB ","B B ","BBBB ","B B ","B B ","BBBB "] alphabet["c"] := [" CCCC ","C ","C ","C ","C "," CCCC "] alphabet["d"] := ["DDDD ","D D ","D D ","D D ","D D ","DDDD "] alphabet["e"] := ["EEEEE ","E ","EEE ","E ","E ","EEEEE "] alphabet["f"] := ["FFFFF ","F ","FFF ","F ","F ","F "] alphabet["g"] := [" GGGG ","G ","G ","G GG ","G G "," GGGG "] alphabet["h"] := ["H H ","H H ","HHHHH ","H H ","H H ","H H "] alphabet["i"] := [" III "," I "," I "," I "," I "," III "] alphabet["j"] := [" JJJ "," J "," J "," J ","J J "," JJ "] alphabet["k"] := ["K K ","K k ","KK ","K K ","K K ","K K "] alphabet["l"] := ["L ","L ","L ","L ","L ","LLLLL "] alphabet["m"] := ["M M ","MM MM ","M M M ","M M ","M M ","M M "] alphabet["n"] := ["N N ","NN N ","N N N ","N NN ","N N ","N N "] alphabet["o"] := [" OOO ","O O ","O O ","O O ","O O "," OOO "] alphabet["p"] := ["PPPP ","P P ","PPPP ","P ","P ","P "] alphabet["q"] := [" QQQ ","Q Q ","Q Q ","Q Q Q ","Q QQ "," QQQQ "] alphabet["r"] := ["RRRR ","R R ","RRRR ","R R ","R R ","R R "] alphabet["s"] := [" SSSS ","s "," SSS "," S "," S ","SSSS "] alphabet["t"] := ["TTTTT "," T "," T "," T "," T "," T "] alphabet["u"] := ["U U ","U U ","U U ","U U ","U U "," UUU "] alphabet["v"] := ["V V ","V V ","V V ","V V "," V V "," V "] alphabet["w"] := ["W W ","W W ","W W W ","WW WW ","W W ","W W "] alphabet["x"] := ["X X "," X X "," X "," X X ","X X ","X X "] alphabet["y"] := ["Y Y "," Y Y "," Y "," Y "," Y "," Y "] alphabet["z"] := ["ZZZZZ "," Z "," Z "," Z ","Z ","ZZZZZ "] alphabet[" "] := [" "," "," "," "," "," "] alphabet["1"] := [" 1 "," 11 "," 1 "," 1 "," 1 "," 111 "] alphabet["2"] := [" 222 ","2 2 "," 2 "," 2 "," 2 ","22222 "] alphabet["3"] := ["3333 "," 3 ","3333 "," 3 "," 3 ","3333 "] alphabet["4"] := ["4 4 ","4 4 ","44444 "," 4 "," 4 "," 4 "] alphabet["5"] := ["55555 ","5 ","5555 "," 5 "," 5 ","5555 "] alphabet["6"] := [" 666 ","6 ","6666 ","6 6 ","6 6 "," 666 "] alphabet["7"] := ["77777 "," 7 "," 7 "," 7 "," 7 "," 7 "] alphabet["8"] := [" 888 ","8 8 "," 888 ","8 8 ","8 8 "," 888 "] alphabet["9"] := [" 999 ","9 9 "," 9999 "," 9 "," 9 "," 999 "] alphabet["0"] := ["00000 ","0 0 ","0 00 ","0 0 0 ","00 0 ","00000 "] alphabet[":"] := [" ::: "," ::: "," "," "," ::: "," ::: "] alphabet["!"] := [" !! "," !! "," !! "," !! "," "," !! "] alphabet["."] := [" "," "," "," "," ... "," ... "] alphabet["?"] := [" ??? ","? ? "," ? "," ? "," "," ? "] alphabet["/"] := [" "," / "," // "," // "," // ","// "] alphabet["-"] := [" "," ","----- ","----- "," "," "] } bline := ["","","","","",""] every byte := !str do { raster := alphabet[map(byte)] every i := 1 to 6 do bline[i] ||:= raster[i] } return bline end From icon-group-sender Mon Sep 20 14:57:32 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Mon, 20 Sep 1993 15:07:35 MST Received: by owl.cs.arizona.edu; Mon, 20 Sep 1993 15:07:34 MST Date: Mon, 20 Sep 93 14:57:32 -0400 From: ptho@seq1.loc.gov (Phillip Lee Thomas) Message-Id: <9309201857.AA05326@seq1.loc.gov> To: icon-group@cs.arizona.edu Subject: Yet another question... Status: R Errors-To: icon-group-errors@cs.arizona.edu About Chris Fagyal's text search problem... There is too little information in the problem to give an optimal answer. Problems are: 1) are all data lines of two lines each? 2) How big is the database? Brute force: Your index lines are totally numeric, so 1)match for a number in column one and see if you can convert the whole line into a number. If you can and the number is the one you are looking for, keep reading until the next index. Indexed: Keep a separate file of where each number is located and seek to that location. The index file could be kept in memory for faster access. Binary: Seek to the middle of your file, read until you get a number line. If the number is too big, seek half way between the start and the current position, etc. Be sure to test your boundaries so that you can retrieve the first and last index lines. Your main problems are over whether the entire file can be kept in memory or only the index or neither and whether you have some structure to the data lines. The icon library has some functions that might provide a model: see idxtext and associated procedures. Phillip Lee Thomas Library of Congress ptho@seq1.loc.gov From icon-group-sender Thu Sep 16 15:42:23 1993 Received: from owl.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Thu, 23 Sep 1993 08:24:47 MST Received: by owl.cs.arizona.edu; Thu, 23 Sep 1993 08:24:46 MST Date: 16 Sep 93 15:42:23 GMT From: pipex!uknet!nessie!goshawk!john@uunet.uu.net (John Heaton) Organization: Manchester Computing Centre Subject: ICON on Linux / Solaris Message-Id: <1993Sep16.154223.29621@nessie.mcc.ac.uk> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu I have recently compile ICON 8.10 up on out SUN 630MP under SUNOS, but have had trouble getting it to compile under Solaris on a SS10/52, and on my 486/33 with Linux. Help!! John -- John Heaton - NRS Central Administrator MCC Network Unit, The University, Oxford Road, Manchester, M13-9PL Phone: (+44) 61 275 6011 - FAX: (+44) 61 275 6040 Packet: G1YYH @ G1YYH.GB7PWY.#16.GBR.EU From icon-group-sender Fri Sep 24 22:51:45 1993 Received: by cheltenham.cs.arizona.edu; Thu, 30 Sep 1993 12:16:50 MST Date: 24 Sep 93 22:51:45 GMT From: tulane!cs.cs.uno.edu!uno.edu!KGPL@ames.arc.nasa.gov Organization: University of New Orleans Subject: Is there a FAQ for this group? Message-Id: <1993Sep24.225145.20523@cs.uno.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Is there a FAQ for this group? How often is it posted and is there an ftp site that carries it? Also, is there usually this little activity here? From icon-group-sender Thu Sep 30 19:13:52 1993 Received: by cheltenham.cs.arizona.edu; Mon, 4 Oct 1993 08:49:23 MST Date: 30 Sep 93 19:13:52 GMT From: munnari.oz.au!pellew.ntu.edu.au!nutmeg!hoffmann@uunet.uu.net (Arthur Hoffmann) Organization: A poorly-installed InterNetNews site Subject: Re: trouble compiling src on UNIX. Message-Id: <28fb5gINN847@pellew.ntu.edu.au> References: <28cd0kINN75q@pellew.ntu.edu.au> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Arthur Hoffmann (hoffmann@nutmeg) wrote: : : : NetBSD is BSD4.3 and I'm using gcc2.4.5. The computer is based on : an 68030 with 68881, no windows. I thought gcc was ansi, but when : using the option #define Standard in define.h not even the first : 3 files get compiled till I get an error. : : If I use -traditional as a compiler option then it compiles, but gives : lots of warnings saying: Integer overflow in expression. The whole directory : then compiles, but at the end when everything gets linked together : it comes up with: xrmisc.o: Undefined _ecvt referenced from text segment. : I now got rid of most problems (thanks to someone who emailed me saying I should configure for sun4_gcc). All the code seems to compile, but this time it comes up with xcnv.o: Undefined symbol _gcvt from text segment. Thank you for your help. -- Arthur. Arthur Hoffmann hoffmann@nutmeg.ntu.edu.au From icon-group-sender Tue Sep 28 19:25:08 1993 Received: by cheltenham.cs.arizona.edu; Mon, 4 Oct 1993 08:56:42 MST Date: 28 Sep 93 19:25:08 GMT From: cis.ohio-state.edu!math.ohio-state.edu!howland.reston.ans.net!agate!linus!progress!neil@ucbvax.Berkeley.EDU (Neil Galarneau) Organization: Progress Software Corp. Subject: Design for icon calling DLL entrypoints? Message-Id: <1993Sep28.192508.6881@progress.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu I am trying to come up with a good way for icon to access DLLs. Dynamic Link Libraries (which exist under MS Windows and OS/2) are pieces of code that can be linked to and executed at runtime. No modification of iconx should have to be done to call DLLs. To access a DLL entrypoint, you need to know the name of the DLL, the name or number of the entrypoint (every entrypoint in a DLL has a number and most have a name), whether the calling convention is pascal or cdecl, and the number and types (short, long, void far *, float, double) of the arguments, and the type of the return value if any. The obvious place to start is with the icon callout(x, x1, ..., xn) function. x could be the name of the entrypoint, but what about the other info DLL access needs? One approach would be to define a record: record dllEntry(dllNameOrOrdinal, callConvention, args) where dllNameOrOrdinal would be a string or integer, callConvention could be a 1 or 0 or maybe a string, and args could be a string encoding the argument and return types. Instead of having all these dllEntry records floating all over the place, maybe we could store these records in a table called dllEntrypoints or something. So when a callout function was executed, I would look up the name, find the associated record, and be on my way. What do people think? Neil neil@progress.com P.S. Is the icon preprocessor able to turn: sndPlaySound("tada.wav", 0) into callout("sndPlaySound", "tada.wav", 0) ? From icon-group-sender Tue Oct 5 10:24:55 1993 Received: by cheltenham.cs.arizona.edu; Tue, 5 Oct 1993 09:17:11 MST Date: Tue, 5 Oct 93 10:24:55 CDT From: jeffery@ringer.cs.utsa.edu (Clinton L. Jeffery) Message-Id: <9310051524.AA24738@ringer.cs.utsa.edu.sunset> To: neil@progress.com@cs.arizona.edu Cc: icon-group@cs.arizona.edu In-Reply-To: (Neil Galarneau's message of 28 Sep 93 19:25:08 GMT <1993Sep28.192508.6881@progress.com> Subject: Design for icon calling DLL entrypoints? Content-Length: 1281 Status: R Errors-To: icon-group-errors@cs.arizona.edu Hi Neil, I think your design for .DLL access is pretty reasonable, but when you implement it you may find a few adjustments will help. For example, it is not easy to predefine a built-in record type in icont/iconx, and I think its not easy to perform an Icon table lookup from within C code in the run-time system. I agree with you that callout() is a reasonable place to start from. If you want to go with callout, I would stick with it entirely and include the name of the entry point in the dll record you were talking about, and just pass that record in as callout's first argument. Alternatively, you could define a new function calldll(dll, x, convention, signature, a1, ..., aN) where x is your name or entry point, and the signature is the string encoding argument and return types as you mentioned. To answer your other question, I believe the Icon preprocessor is not yet powerful enough to turn sndPlaySound("tada.wav", 0) into callout("sndPlaySound","tada.wav", 0). Icon procedures are very good for this sort of thing, and for the table mapping names to records (should you decide to go with your record-based design). It sounds like fun. Good luck! Clint Jeffery cjeffery@cs.arizona.edu -or- jeffery@ringer.cs.utsa.edu The University of Texas at San Antonio From icon-group-sender Sat Oct 2 13:49:27 1993 Received: by cheltenham.cs.arizona.edu; Thu, 7 Oct 1993 08:41:16 MST Date: 2 Oct 93 13:49:27 GMT From: cis.ohio-state.edu!magnus.acs.ohio-state.edu!math.ohio-state.edu!wupost!tulane!cs.cs.uno.edu!uno.edu!KGPL@ucbvax.Berkeley.EDU Organization: University of New Orleans Subject: Self-Extending/Modifying Code Message-Id: <1993Oct2.134927.4078@cs.uno.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Can one write code in Icon that extends or modifies itself during run-time? It has been suggested to me that this can be done, but after reading/browsing (depending on the chapter) the 1990 edition of the Griswolds' book, I can find no way to do this. Admittedly I can use the "create" command to do something like this, but only if I write the code that I wish to add myself. What I would like to do is something like this... Imagine a procedure that randomly generates legal icon procedures. Procedures that do not appear anywhere in the code currently being run. I would like to be able to generate a totally new procedure, store it as a string (or whatever is appropriate) in a variable, and then jump command to that string/program just created. All of this during run-time. Something like: my_program := random_code() my_program() Ideally, there should be a way to get the origional code to make changes to itself, as well. However this is too much to hope for. Any help would be appreciated. kgpl@jazz.ucc.uno.edu From icon-group-sender Fri Oct 8 05:07:26 1993 Received: by cheltenham.cs.arizona.edu; Fri, 8 Oct 1993 08:17:59 MST Via: uk.ac.edinburgh.festival; Fri, 8 Oct 1993 13:07:02 +0100 Date: 08 Oct 93 13:06:52 BST From: R J Hare Subject: Various questions To: icon-group@cs.arizona.edu Reply-To: r.j.hare@edinburgh.ac.uk Organisation: Edinburgh University Computing Service Message-Id: <9310081306.aa17911@uk.ac.ed.festival> Status: R Errors-To: icon-group-errors@cs.arizona.edu I have three questions: 1) What is the 'best' (ie: most random) way to seed the random number generator in a particular situation. Currently, I do something like: &random:=&date[6:8]||&date[9:11]||&clock[1:3]||&clock[4:6]||&clock[7:9] which produces a 10 digit number as a seed. Would I be 'better' using just the six digits obtained from &clock? 2) The above syntax is tedious. Is there a better way (I am sure there is)? In particular, can I say: &random:=&date[6:8||9:11]||&clock[1:3||4:6||7:9] where the ||s represent some way of concatenating substrings of a value whilst referring to that value only once. 3) If I have a list which is (say) 10 elements long, what happens if I assign a value to list[12]? Is an empty (null) list[11] created? I have tried this, and the assignment appears to fail and the list length is unchanged, so what is happening 'behind the scenes'? I wouldn't ask these daft questions but I and my Icon book are several miles away from each other and are unlikely to rejoin eachother for several days. Thanks. Roger Hare. From icon-group-sender Tue Oct 5 23:58:34 1993 Received: by cheltenham.cs.arizona.edu; Sun, 10 Oct 1993 10:17:10 MST Date: 5 Oct 93 23:58:34 GMT From: math.fu-berlin.de!uniol!Roland.Radtke@uunet.uu.net (Roland Radtke) Organization: University of Oldenburg, Germany Subject: Where's the FAQ? Grammar/introduction wanted. Message-Id: <1993Oct6.000249.14414@arbi.Informatik.Uni-Oldenburg.DE> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Hi! I'm looking for a FAQ on icon, or, if possible, for a grammar and a language introductory course in electronically retrievable from. Thank you for bothering, Roland. From icon-group-sender Wed Oct 6 13:59:52 1993 Received: by cheltenham.cs.arizona.edu; Sun, 10 Oct 1993 10:18:00 MST Date: 6 Oct 93 13:59:52 GMT From: math.fu-berlin.de!news.belwue.de!iptc!news.wsi!peanuts!sperber@uunet.uu.net (Michael Sperber [Mr. Preprocessor]) Organization: Lehrstuhl fuer Technische Inforrmatik, Uni Tuebingen Subject: Controlling programs via pty from Icon Message-Id: Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu I recently had to write a program which had to control an interactive ML interpreter through a pipe or something equivalent. Since Icon is just fantastic for analyzing the output from the ML system, it was a natural choice. It turned out that Icon pipes were inadequate for the simple reason that they can only either read or write. Even a simple C program that opens a two-way pipe and writes the output into a file won't cut it. So I had to mess with ptys and finally came up with a program (the "flusher") that starts a job on a pty and flushes its output after every line. That means I can do something like: f_ml := open(flusher || " " || compiler || " > " || fn_ml_msgs || " 2>&1", "pw") | And be sure the output gets into the redirected file when as soon as a newline is printed. It's a KLUDGE, to be sure. Now, if anyone is interested, I can mail it. I've written it under AIX, but using only code gleaned from Sun and Linux manuals, so it might actually work on other machines. The more fundamental question: Wouldn't ptys disguised as two-way pipes make a neat addition to the open function in Icon? Cheers =8-} Chipsy From icon-group-sender Wed Oct 6 19:13:05 1993 Received: by cheltenham.cs.arizona.edu; Sun, 10 Oct 1993 21:32:25 MST Date: 6 Oct 93 19:13:05 GMT From: walter!news@uunet.uu.net (Darren New) Organization: Bellcore Subject: Re: Controlling programs via pty from Icon Message-Id: <1993Oct6.191305.12061@walter.bellcore.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Actually, I'd like a way to do asynchronous reading. Polling or select or some such, if possible, in order that servers could be written in Icon. I have a very kludgy way to do it that actually has some advantages, but I'd like to hear if there's already a better solution than adding things to the interpreter. Also, the code mentioned I would like to see. -- Darren Darren New, MTS (MIME compliant) 445 South St/MRE 2E-279/Morristown NJ 07960 USA/(201)829-4833 Delivery of Electronic Multimedia over Networks (DEMON) Also, formal description techniques, programming languages. ``Your fault: Core dumped.'' EFF#846 ``Sometimes, you just have to bite the silver bullet.'' From icon-group-sender Mon Oct 18 15:10:50 1993 Received: by cheltenham.cs.arizona.edu; Wed, 20 Oct 1993 07:42:56 MST Date: 18 Oct 93 15:10:50 GMT From: agate!howland.reston.ans.net!math.ohio-state.edu!magnus.acs.ohio-state.edu!csn!cherokee!NewsWatcher!user@ucbvax.Berkeley.EDU (Radford Walker) Organization: U S WEST Advanced Technologies Subject: SNOBOL4 Message-Id: Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Since there appears to be no discussion dedicated to SNOBOL4 I was wondering if anyone here might be able to help. I have a program that has a table using strings as the indexing element. After the complete table is built, I work through another file looking for matches in the table. It works great but is taking more memory than I want it to. Is there some way to free a single table element once I am finished with it? Is there a way to clear the entire table? I thought that TABLE = NULL would free the memory during the next garbage collection. I also thought that C = TABLE() would clear the entire table "C" and begin it fresh. Does anyone know for certain? |---------------------------------------------------------------------| |These are own opinions not that of my company or the echo moderator | |Any relation to the truth is pure coincidence. Spelling! What's that?| | Radford Walker - rwalker@atqm.advtech.uswest.com | | OS/2 - because 32 bits are terrible things to waste. | |^_^_^_^_^_^_^_^_^_^_^_^_^_^_^_^_^_^_^_^_^_^_^_^_^_^_^_^_^_^_^_^_^_^_^| From icon-group-sender Wed Oct 20 11:01:27 1993 Received: by cheltenham.cs.arizona.edu; Wed, 20 Oct 1993 13:34:49 MST Message-Id: <199310201609.AA29993@optima.CS.Arizona.EDU> Date: Wed, 20 Oct 93 11:01:27 CDT From: "Viktors Berstis" X-Addr: tieline 793-1547 (512)823-1547 MS 2990 IBM 11400 Burnet Rd Austin, TX 78758 To: icon-group@cs.arizona.edu Subject: SNOBOL4 and TABLEs Status: R Errors-To: icon-group-errors@cs.arizona.edu In regard to your question about putting null entries in SNOBOL4 TABLES. They in fact do occupy another slot in the TABLE. A way to fix this is to make sure the table contains at least one non-null value. Then convert it to an array and then convert it back. Remember to get rid of the array. This won't solve your problem if you happen to have named references to entries in the table: X = TABLE() X<123> = NULL Q = .X<123> Q will make the old table hang around, in case you might use Q to store a new value in that table entry (be it null or something else). If you don't do the above, you can periodically clean up by converting to the array and back. -Viktors From icon-group-sender Sat Oct 23 04:14:11 1993 Received: by cheltenham.cs.arizona.edu; Sat, 23 Oct 1993 13:46:53 MST Date: 23 Oct 93 04:14:11 GMT From: sdd.hp.com!portal!cup.portal.com!Eric-Amick@hplabs.hpl.hp.com (Richard E Amick) Organization: The Portal System (TM) Subject: Re: icon textbook Message-Id: <93950@cup.portal.com> References: <1993Oct22.163205.20613@bmerh85.bnr.ca> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu There aren't a lot of books about Icon. The definitive book is probably "The Icon Programming Language, 2nd edition" by Ralph and Madge Griswold. It's published by Prentice Hall. If you drop a line to the Icon Project (the developers of Icon) at icon-project@cs.arizona.edu, they can suggest other books and even sell you some. From icon-group-sender Fri Oct 22 16:32:05 1993 Received: by cheltenham.cs.arizona.edu; Mon, 1 Nov 1993 08:54:35 MST Date: 22 Oct 93 16:32:05 GMT From: pipex!bnr.co.uk!bnrgate!bmerha64.bnr.ca!bmerh85!bmerha06!mgarvin@uunet.uu.net (Donald Cameron) Organization: Bell-Northern Research, Ottawa, Canada Subject: icon textbook Message-Id: <1993Oct22.163205.20613@bmerh85.bnr.ca> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: RO Errors-To: icon-group-errors@cs.arizona.edu Hi, I've recently downloaded a copy of icon, but I don't know of a good book, for an introduction to the language. If anyone knows of a 'kinder gentler' text that has a fair number of examples, could you post its title. This has probably been asked before, so if you can point me to a faq file somewhere... point away! thanks for any help! Michael J. Garvin 763-8309 mgarvin@bnr.ca Sysdoc dept. 8I32 Bell Northern Research ___ |\ | | | \ / | \| |___| \/\/ is the only thing thats real! From icon-group-sender Fri Oct 22 20:14:55 1993 Received: by cheltenham.cs.arizona.edu; Mon, 1 Nov 1993 08:55:20 MST Date: 22 Oct 93 20:14:55 GMT From: walter!news@uunet.uu.net (Darren New) Organization: Bellcore Subject: Re: icon textbook Message-Id: Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: RO Errors-To: icon-group-errors@cs.arizona.edu The Icon Programming Language, 2nd edition Ralph E. Griswold & Madge T. Griswold ISBN 0-13-447889-4 From icon-group-sender Fri Oct 22 20:17:11 1993 Received: by cheltenham.cs.arizona.edu; Mon, 1 Nov 1993 08:55:51 MST Date: 22 Oct 93 20:17:11 GMT From: walter!news@uunet.uu.net (Darren New) Organization: Bellcore Subject: Icon compiler Message-Id: Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: RO Errors-To: icon-group-errors@cs.arizona.edu Anybody have any idea what all the parameters to the Icon compiler are? I know I'm not supposed to use it, but I thought I'd play around with it. -- Darren -- 445 South St/MRE 2E-279/Morristown NJ 07960 USA/(201)829-4833 Delivery of Electronic Multimedia over Networks (DEMON) Also, formal description techniques, programming languages. ``Your fault: Core dumped.'' EFF#846 ``Sometimes, you just have to bite the silver bullet.'' From icon-group-sender Sat Oct 23 22:38:27 1993 Received: by cheltenham.cs.arizona.edu; Mon, 1 Nov 1993 08:56:08 MST Date: 23 Oct 93 22:38:27 GMT From: elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!math.ohio-state.edu!pacific.mps.ohio-state.edu!linac!uchinews!ellis!goer@ames.arc.nasa.gov (Richard L. Goerwitz) Organization: University of Chicago Subject: Re: Icon compiler Message-Id: <1993Oct23.223827.20560@midway.uchicago.edu> References: Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: RO Errors-To: icon-group-errors@cs.arizona.edu Darren New writes: >Anybody have any idea what all the parameters to the Icon compiler are? >I know I'm not supposed to use it, but I thought I'd play around with >it. There should be a manual page for icon. If it is current, it will cover both "icont" (the interpreter we all use) and "iconc" (the rather experi- mental compiler). Check with your local sysadmin to see if the manual page has been installed. If not, you might ask where the source tree is, and if it is online, try checking the "docs" directory at the top level of that tree. Good luck. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Tue Nov 2 22:22:21 1993 Received: by cheltenham.cs.arizona.edu; Wed, 3 Nov 1993 07:39:35 MST Date: Tue, 2 Nov 93 22:22:21 MST From: whm@majortom.sunquest.com (Bill Mitchell) Message-Id: <9311030522.AA04362@majortom.sunquest.com> To: icon-group@cs.arizona.edu Subject: Icon allowed in this year's Internet Programming Contest Status: RO Errors-To: icon-group-errors@cs.arizona.edu The following is the announcement for the Fourth Annual Duke Internet Programming Contest. This year's contest is allowing an expanded set of languages and Icon is included among them. I was in a team in the contest last year and I had a great time. I highly recommend it. Here's the announcement...GO FOR IT! A N N O U N C I N G The Fourth Annual Internet P R O G R A M M I N G C O N T E S T On the evening of Thursday, November 18, 1993, members of the Duke University Department of Computer Science will sponsor the Fourth Internet Programming Contest, similar in style to the ACM programming contests, but taking place over the Internet. The contest involves teams of programmers solving a set of problems with a single computer. The team that solves the most problems in the allotted time wins the contest (similar to the usual ACM programming contest rules). We want to encourage everyone to participate. This is just for fun (i.e., there are no prizes, except bragging rights). To this end, based on comments received from last year's contest, we have endeavored to make the problem set cover a broad range in level of problem difficulty. Although we cannot guarantee it, we expect that a person with at least two introductory programming courses should be able to solve at least one problem. Of course we will attempt to include problems that will challenge even the most expert of programmers. New this year: many new programming languages are supported. We will accept program submissions in C, C++, Objective C, Pascal, FORTRAN, Scheme, Haskell, Perl, and Icon. Other languages will be considered for inclusion through November 10, so if you would like to participate using another language, please contact us. Previous year's problem sets are available for anonymous ftp from the host cs.duke.edu in the directory dist/misc/acm_contest. There are three files: problems90.tar.Z, problems91.tar.Z, and problems92.tar.Z. This year's problems will be made available some time after November 19. Key information about our contest: o Thursday, November 18, 1993, from 6 PM to 9 PM Eastern Standard Time. (you will need to be ready at least a half-hour ahead of time). Individual team registration begins about one hour prior to the contest. o All teams will work at their own site, and submit solutions and clarification requests to the judges at Duke via email. We expect that participants have a fast e-mail connection: Anything more than about a 15 minute delay will put your team at a disadvantage. o Preregistration is necessary for any interested SITE; individual teams at each site may register at the start of the contest. o Sites should preregister by sending mail to khera@cs.duke.edu BEFORE Tuesday November 16. There should be a *single* contact person at each site who can install our software (three /bin/sh scripts) and coordinate local teams (as many teams as you want.) The individual teams will register at the start of the contest. Please fill out the form below to register your site. o You may use any Unix machine, but programs must be written in either Classic C, ANSI C, C++, Pascal, FORTRAN, Haskell, Perl, Icon, or Scheme. We will use the following versions of the compilers or interpreters on a SPARCstation running SunOS 4.1.3: Language Compiler & Version -------- ------------------ C gcc 2.5.0 C++ gcc 2.5.0 Objective-C gcc 2.5.0 Pascal Sun Pascal 2.1 FORTRAN Sun FORTRAN 1.4 Scheme scm 4c5 (Revised^4 Scheme interpreter) Haskell hbc Perl perl 4.036 (interpreter) Icon icont 8.10 (interpreter) o Maximum of four people per team, and only one keyboard/display per team. o Three divisions for scoring purposes: 1. novice 2. expert single (teams with only one member) 3. expert team There will be a subset of problems for which only novice teams will be given credit, and a subset of the problems for which only expert teams will be credited. So, for instance, if there were 4 problems in the contest, problem 1 might be restricted to the expert teams, problem 2 might be restricted to the novice teams. All teams would be scored on the remaining problems. o Three to eight problems, posed in English. o Honesty of all participants is assumed. o Specific rules and logistics will be sent to the official contact person for each site approximately one week prior to the contest. Last year's contest consisted of 6 problems, and had nearly 300 teams participating from around the globe. We look forward to having another great turnout this year. Contacts: Vick Khera khera@cs.duke.edu Owen Astrachan ola@cs.duke.edu Note that Email address should be a valid Internet address, so I can send you mail. Also, please don't modify the form itself, as it is automatically processed (leading blanks or other characters inserted by the "reply" function of mail or news are acceptable). If your site doesn't have a name, or you don't wish to provide it, please substitute your geographic location, so we know generally where you are. example of properly filled out form: Site Contact Name: Vick Khera Email address: khera@cs.duke.edu Site Name: Duke University CS Department, Durham, NC Improperly filled out pre-registration forms will most likely be ignored. --cut here-- DIPC SITE REGISTRATION FORM ====================== Site Contact Name: Email address: Site Name: E-mail this form to khera@cs.duke.edu prior to November 16, 1993. Additional information will be sent to you approximately one week prior to the contest date. --cut here-- From icon-group-sender Wed Nov 3 15:54:31 1993 Received: by cheltenham.cs.arizona.edu; Wed, 3 Nov 1993 18:18:48 MST From: "Art Eschenlauer" Message-Id: <9311032154.AA17470@molbio.cbs.umn.edu> Subject: stand alone icon for mac, slight improvement To: icon-group@cs.arizona.edu Date: Wed, 3 Nov 93 15:54:31 CDT X-Mailer: ELM [version 2.3test PL26] Status: R Errors-To: icon-group-errors@cs.arizona.edu I have tweeked the source code for the stand alone version of Icon for the macintosh. The original uses the directory in which the APPLICATION is located as the default directory, for the icon "open" statement, etc.. Effectively, this means that ALL your data files must be in the same directory (folder) as the application, or that you must move the application from directory to directory. To me, at least, it is more intuitive if the directory in which the code file (the PROGRAM) is located is used as the default directory. I have programmed around this problem. If anyone wants the modified interpreter posted to the ftp site, mail me, and I will do what I can to take care of it. Since I had to modify the source code for console.c, which is part of the ThinkC package, I cannot post the source code, though if you own ThinkC 5 then I can work something out with you if you want. -Art Eschenlauer (eschen@molbio.cbs.umn.edu) From icon-group-sender Mon Oct 25 16:30:50 1993 Received: by cheltenham.cs.arizona.edu; Mon, 8 Nov 1993 08:10:39 MST Date: 25 Oct 93 16:30:50 GMT From: cis.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!howland.reston.ans.net!pipex!uknet!glasgow!sansom@ucbvax.Berkeley.EDU (Patrick Sansom) Organization: Glasgow University Computing Science Dept. Subject: Profiling Message-Id: Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu What profiling tools do you use? Are they satisfactory? I want to build up a picture of what profiling tools are available for high level languages such as Scheme, Lisp, Icon, SmallTalk, Prolog. I would greatly appreciate if you would tell me about your favorite profiling tool. In particular: What language is it for? What facilities does it provide? Does it profile time, space or both? What profiling techniques does it use? How does it present the profiling data? What do you find most useful? Any references to papers and/or documentation. I will post a summary of responses. Thanks in advance, Patrick. -- Patrick Sansom | E-Mail: sansom@dcs.glasgow.ac.uk Computing Science Research Student | Real-Mail: Dept. of Computing Science, University of Glasgow | The University, Phone: (41) 339-8855 x 8332 | Glasgow G12 8QQ From icon-group-sender Mon Nov 8 10:18:34 1993 Received: by cheltenham.cs.arizona.edu; Mon, 8 Nov 1993 08:12:44 MST Via: uk.ac.edinburgh.festival; Mon, 8 Nov 1993 10:19:03 +0000 Date: 08 Nov 93 10:18:34 GMT From: R J Hare Subject: Various questions: To: icon-group@cs.arizona.edu Reply-To: r.j.hare@edinburgh.ac.uk Organisation: Edinburgh University Computing Service Message-Id: <9311081018.aa23405@uk.ac.ed.festival> Status: R Errors-To: icon-group-errors@cs.arizona.edu 1) Has anyone written a language tutor/vocabulary drill program (or something similar) in Icon. I am interested in a French language tutor or similar? 2) Are there any French language papers/articles/w.h.y. which describe Icon. Thanks. Roger Hare. From icon-group-sender Sat Oct 30 16:59:02 1993 Received: by cheltenham.cs.arizona.edu; Tue, 9 Nov 1993 19:26:09 MST Date: 30 Oct 93 16:59:02 GMT From: uchinews!iitmax!rice.iit.edu!rubxv097@speedy.wisc.edu (Boo) Organization: Illinois Institute of Technology, Rice Campus Subject: XXX to C translator Message-Id: <1993Oct30.165902.14797@glen-ellyn.iit.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Hi, I want to write a translator that will take a code of PASCAl like language and produce C code. Will icon be a good choise for implementation? Has anybode ever done something similar using icon? Please reply to vaysbor@elof.iit.edu Thanx. From icon-group-sender Wed Nov 3 10:57:56 1993 Received: by cheltenham.cs.arizona.edu; Fri, 12 Nov 1993 19:15:18 MST Date: 3 Nov 93 10:57:56 GMT From: pipex!uknet!mcsun!sunic!sics.se!sics.se!soder@uunet.uu.net (Hakan Soderstrom) Organization: Swedish Institute of Microelectronics, Kista Subject: Icon debugging and MT-Icon Message-Id: <1993Nov3.105756.909@sics.se> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu I have acquainted myself to the ingenious 'debugify' by Charles Shartsis. After having seen a 100 kb odd 'u1' file grow to over a megabyte after 'debugify' I feel troubled about the ungrateful task of this approach. One conspicuous problem is the amount of code 'debugify' must generate in order to allow the debug procedure inspect variables at run-time. Not only does the program grow in size; there is a lot more to execute, although most of the time the results are unused. It seems that Icon needs a few more self-probing functions. The 'display' function shows that run-time Icon is very aware of its calling stack and variable names (of course). One would wish that 'display' was not constrained to ship everything it finds to a file. With 'debugify' one would like to have the same data packed up in a list of tables, for instance. These questions sent me to the runtime source code. While there I discovered functions named 'localnames' etc. These functions would seem to have a bearing on the debugging problem. They are, however, bracketed by 'MultiThread' conditional compilation. Vague recollections of 'MT-Icon' (Multi-Thread) mentioned in either the Newsletter or the Analyst seemed to cross my mind. Knowing next to nothing about MT-Icon, my question is: Will MT-Icon obviate the need for other debugging extensions to Icon? Hakan Hakan Soderstrom, Soderstrom Programvaruverkstad AB, Sweden soder@inmic.se From icon-group-sender Fri Nov 12 21:30:33 1993 Received: by cheltenham.cs.arizona.edu; Sat, 13 Nov 1993 16:50:04 MST Date: Fri, 12 Nov 93 21:30:33 CST From: jeffery@runner.jpl.utsa.edu (Clinton L. Jeffery) Message-Id: <9311130330.AA14375@runner.utsa.edu> To: icon-group@cs.arizona.edu In-Reply-To: <1993Nov3.105756.909@sics.se> (pipex!uknet!mcsun!sunic!sics.se!sics.se!soder@uunet.uu.net) Subject: Re: Icon debugging and MT-Icon Content-Length: 830 Status: R Errors-To: icon-group-errors@cs.arizona.edu > Hakan Soderstrom writes: > Knowing next to nothing about MT-Icon, my question is: Will MT-Icon > obviate the need for other debugging extensions to Icon? Yes, MT Icon is intended to allow the construction of debuggers for Icon in Icon. An Icon program can load another Icon program (producing a co-expression value corresponding to a call to its main() procedure), and then control its execution, inspect and modify its variables, etc. Execution control is driven by an event model. We have mostly used it so far for program visualization tools, and there are one or two things (like variable traps) I'd like to add especially for debugging, but the code for MT Icon and monitoring has been used for some time now by a number of people. Clint Jeffery, jeffery@ringer.cs.utsa.edu The University of Texas at San Antonio From icon-group-sender Sun Nov 14 10:59:33 1993 Received: by cheltenham.cs.arizona.edu; Mon, 15 Nov 1993 09:05:48 MST Date: 14 Nov 93 10:59:33 GMT From: noc.near.net!news.delphi.com!usenet@uunet.uu.net (Will Mengarini) Organization: Delphi Internet Subject: Re: dos executables from icon Message-Id: <931114.21573.MENGARINI@delphi.com> References: <93312.000307U47041@uicvm.uic.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu I have implemented a system for doing this. I e-mailed the Icon Project 2 months ago to tell them about it, then Ralph Griswold a month later, but in neither case did I get a reply; Griswold is on sabbatical thru 1994, & the I.P. never answered. During the process of coding my implementation for producing a DOS .Exe file using IconT, I discovered that there was code #ifdeffed out that seemed to implement the same kind of thing on other operating systems, but vital components of that "header" subsystem are not included in the MS-DOS distribution. There's other stuff that's also not included; I don't know what "the variant translator subsystem" is since I've never seen it, but I have a whole list of changes I want to make to the language, & it'll be a real pain to be reinventing a wheel unnecessarily. I get the feeling MS-DOS is treated with too much contempt by the Icon Project; sure it's dumb, but it's ubiquitous, & now it's typically used on very powerful hardware that, in protected mode, can offer a 16M address space & lots of disk space. Any system that can handle C++ can handle the full Icon system, & omitting essential stuff like these items from the distribution is really inconveniencing a large group of potential users. Mistakes like these might explain why there's so little activity in the newsgroup of such a brilliant language. For my next trick, I want to rebuild Icon{T,X} to run in protected mode under Phar Lap's 16-bit DOS extender. I wouldn't be surprised if somebody has done this already; if so, please post your Make file. I'll try to also integrate my .Exe system with that, but your Make file will help as a starting point even if you haven't worked on the .Exe problem. Because I got no response from the Icon Project & concluded nobody was home, I assumed there was no interest in an adaptation to handle .Exe files, & I haven't packaged it into something easily distributable. I'll start working on that, but it'll take a week or two; I typically spend an entire week sleeping at the office, & I only get onto this newsgroup on weekends, so I can't do it any faster. Also, has anybody else solved the MS-DOS .Exe problem? We could compare notes. From icon-group-sender Sun Nov 14 19:31:48 1993 Received: by cheltenham.cs.arizona.edu; Mon, 15 Nov 1993 09:06:56 MST Date: 14 Nov 93 19:31:48 GMT From: agate!howland.reston.ans.net!vixen.cso.uiuc.edu!uchinews!ellis!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Subject: Re: dos executables from icon Message-Id: <1993Nov14.193148.21881@midway.uchicago.edu> References: <93312.000307U47041@uicvm.uic.edu>, <931114.21573.MENGARINI@delphi.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Will Mengarini writes: > >I have a whole list of changes I want to make to the language, >& it'll be a real pain to be reinventing a wheel unnecessarily. >I get the feeling MS-DOS is treated with too much contempt by >the Icon Project I had this feeling for some time, too. The reality is, though (IMHO), that the Icon Project is fairly small, and has limited resources. They, unlike many academics, see service as an inte- gral part of their work. Still, they don't have the resources to pour money and development time into old, limited operating sys- tems like MS-DOS - one that doesn't serve any of their research goals. I, for one, frequently compose software for my wife's office - which is still riding on DOS and Windows. I'd be very interested in anything you produce. Thanks for informing us all of your work. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Mon Nov 15 05:09:26 1993 Received: by cheltenham.cs.arizona.edu; Mon, 15 Nov 1993 09:07:26 MST Date: Mon, 15 Nov 1993 05:09:26 MST From: "Ralph Griswold" Message-Id: <199311151209.AA16176@cheltenham.cs.arizona.edu> To: icon-group Subject: MS-DOS Icon executables Status: R Errors-To: icon-group-errors@cs.arizona.edu We received both of Mr. Mengarini's earlier messages on this subject and responded requesting that he send the material he has to us. We heard nothing further. This is no doubt one of those communication problems that sometimes happen with electronic mail and leave the impression of disinterest on both sides. As Richard Goerwitz said, we have very limited resources and can't do everything everyone would like us to do. We also have limited technical competence in some areas, including MS-DOS. We rely, instead, on the contributions of persons outside our organization. That's the way that most implementations of Icon were done originally. We incorporate such contributions and provide what support we can for them. Since we have limited resources, we have to be selective about what we do. We try to strike a balance between innovation and support. At present, we're putting most of our effort into enhancing the graphics capabilities of Icon. Although we're not fond of MS-DOS, we recognize its importance. There are far and away more Icon installations for MS-DOS than for any other platform and this situation probably will continue for the foreseeable future. We've put a great deal of time and effort into the MS-DOS implemementation of Icon in the past and no doubt will continue to do so. However, we also have to consider newer systems, like NT. On the subject of "re-inventing the wheel", many platform-specific things have been done for Icon. The variant translator system presently is supported only for UNIX, but it could be adapted to any platform that has a robust version of Yacc. Documentation is available for variant translators and other support tools and extensions to Icon via FTP or FTPmail. Ralph E. Griswold ralph@cs.arizona.edu Department of Computer Science uunet!arizona!ralph The University of Arizona 602-621-6609 (voice) Tucson, AZ 85721 602-621-9618 (fax) for Icon From icon-group-sender Mon Nov 15 12:07:19 1993 Received: by cheltenham.cs.arizona.edu; Tue, 16 Nov 1993 15:03:26 MST Date: 15 Nov 93 12:07:19 GMT From: agate!howland.reston.ans.net!xlink.net!ira.uka.de!i41s19!angelo@ucbvax.Berkeley.EDU (Angelo Schneider Betr.Prechelt) Organization: University of Karlsruhe, FRG Subject: LR or LALR Parser Generator wanted. Message-Id: <2c7rdnINN7v1@iraun1.ira.uka.de> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Hi, some monthes ago somebody (Goerwitz/Griswold) posted an Parser Generator for Icon. I think there was first a LALR and later a LR Version. Where can I get it? I did not found it in the IPL! angelo --------------------------------------------------------------------------- * | Angelo Schneider *** *** @@@@@/| angelo@ira.uka.de | Edelsheimstr. 1 ******* @@@@/#| Institut fuer Programm- und | D-7500 Karlsruhe 1 ******* @@@/##| Datenorganisation | voice: ++49-721-607840 ******* @@/---| Universitaet Karlsruhe TH | fax: after announcing ** ** @/ | no opinion, I go with the mass!| on voiceline or ^378331 From icon-group-sender Mon Nov 15 12:14:54 1993 Received: by cheltenham.cs.arizona.edu; Tue, 16 Nov 1993 15:05:12 MST Date: 15 Nov 93 12:14:54 GMT From: agate!howland.reston.ans.net!xlink.net!ira.uka.de!i41s19!angelo@ucbvax.Berkeley.EDU (Angelo Schneider Betr.Prechelt) Organization: University of Karlsruhe, FRG Subject: Problem with ICONC under linux. Message-Id: <2c7rruINN7v1@iraun1.ira.uka.de> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Hello everybody, After installing and testing and and and ... I encountered a smal Problem at the end. I moved the binaries and applied "patchstr" on them but ICONC still wants to search for its rt.db file and the other stuff it needs at the old location where I had built them. What to do about this? patchstr noted it patched iconc at one location. icont was patched on two locations! Also there was one Problem linking iconx. I had to undefine something like "EvtMonitor". Something like this was mentioned in an earlyer posting. But it workes only BEFOR you do a make Configure=paltform. After all I'm impressed about the performance difference of Icon under DOS and Icon under Linux! Also iconc seems to be a very good work. ciao, angelo --------------------------------------------------------------------------- * | Angelo Schneider *** *** @@@@@/| angelo@ira.uka.de | Edelsheimstr. 1 ******* @@@@/#| Institut fuer Programm- und | D-7500 Karlsruhe 1 ******* @@@/##| Datenorganisation | voice: ++49-721-607840 ******* @@/---| Universitaet Karlsruhe TH | fax: after announcing ** ** @/ | no opinion, I go with the mass!| on voiceline or ^378331 From icon-group-sender Tue Nov 16 15:26:25 1993 Received: by cheltenham.cs.arizona.edu; Tue, 16 Nov 1993 19:21:47 MST Date: Tue, 16 Nov 93 15:26:25 MST From: cliff (Cliff Hathaway) Message-Id: <9311162226.AA01957@javelina.cs.arizona.edu> To: icon-group Subject: Re: Problem with ICONC under linux Content-Length: 2609 Status: R Errors-To: icon-group-errors@cs.arizona.edu > Date: 15 Nov 93 12:14:54 GMT > From: agate!howland.reston.ans.net!xlink.net!ira.uka.de!i41s19!angelo@ucbvax.Berkeley.EDU (Angelo Schneider Betr.Prechelt) > Subject: Problem with ICONC under linux. > To: icon-group@cs.arizona.edu > > Hello everybody, > > After installing and testing and and and ... > I encountered a smal Problem at the end. I moved the binaries and applied > "patchstr" on them but ICONC still wants to search for its rt.db file and > the other stuff it needs at the old location where I had built them. > What to do about this? > patchstr noted it patched iconc at one location. icont was patched on > two locations! Hmm -- did you carefully follow the instructions in ipd218 "Installing Icon on UNIX Platforms"? 1) make CopyLib Target=directory where directory is the location that you want the iconc auxiliary files to live; 2) patchstr iconc-location directory/ where iconc-location is where iconc currently is, and directory is the directory that the auxiliary files live in. Note the mandatory slash following the full path name to the auxiliary directory. To shamelessly borrow from ipd218.doc: "For example, if iconc is moved to /usr/local/iconc and the files needed by iconc are placed in the directory /usr/local/icon/iconc.lib, the patching step is patchstr /usr/local/iconc /usr/local/icon/iconc.lib/ Or are you sure you're running the iconc in the new location? (Does linux have a "which" command?) > > Also there was one Problem linking iconx. I had to undefine something > like "EvtMonitor". Something like this was mentioned in an earlyer posting. > But it workes only BEFOR you do a make Configure=paltform. The "make Configure name=platform" step copies many platform specific macros and configuration details into the src directory. So you have to run make Configure again if you alter any of the files in the config/unix/ directory. > > After all I'm impressed about the performance difference of Icon under > DOS and Icon under Linux! Also iconc seems to be a very good work. > > ciao, > angelo > > --------------------------------------------------------------------------- > * | Angelo Schneider > *** *** @@@@@/| angelo@ira.uka.de | Edelsheimstr. 1 > ******* @@@@/#| Institut fuer Programm- und | D-7500 Karlsruhe 1 > ******* @@@/##| Datenorganisation | voice: ++49-721-607840 > ******* @@/---| Universitaet Karlsruhe TH | fax: after announcing > ** ** @/ | no opinion, I go with the mass!| on voiceline or ^378331 > > From icon-group-sender Mon Nov 8 06:03:07 1993 Received: by cheltenham.cs.arizona.edu; Thu, 18 Nov 1993 07:23:42 MST Date: 8 Nov 93 06:03:07 GMT From: cis.ohio-state.edu!math.ohio-state.edu!howland.reston.ans.net!vixen.cso.uiuc.edu!bert.eecs.uic.edu!uicvm.uic.edu!u47041@ucbvax.Berkeley.EDU Organization: University of Illinois at Chicago, ADN Computer Center Subject: dos executables from icon Message-Id: <93312.000307U47041@uicvm.uic.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Pardon if the question is astupid one but my connection to hte internet is a shaky one and i have lots of trouble even ftp ing so :how is possible to get a dos executable from an icon source please e mail the answers to kapoulas@wagner.lac.math.uic.edu thank you in advance From icon-group-sender Wed Nov 17 00:26:12 1993 Received: by cheltenham.cs.arizona.edu; Thu, 18 Nov 1993 19:09:18 MST Date: 17 Nov 93 00:26:12 GMT From: walter!flaubert!norman@uunet.uu.net (Norman Ramsey) Organization: Bellcore Subject: Re: Problem with ICONC under linux. Message-Id: References: <2c7rruINN7v1@iraun1.ira.uka.de> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu In article <2c7rruINN7v1@iraun1.ira.uka.de> angelo@i41s19.ira.uka.de (Angelo Schneider Betr.Prechelt) writes: >After all I'm impressed about the performance difference of Icon under >DOS and Icon under Linux! What is this performance difference? Norman From icon-group-sender Mon Nov 8 23:00:26 1993 Received: by cheltenham.cs.arizona.edu; Thu, 18 Nov 1993 19:10:19 MST Date: 8 Nov 93 23:00:26 GMT From: att-out!cbnewsh!cbnewse!ihlpf!pax@rutgers.edu (joe.t.hall) Organization: AT&T Bell Labs Subject: Solaris port Message-Id: Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu I missed an earlier posting of someone doing the port of Icon 8.10 to the Solaris platform. I am interested in this port and would like to connect with anyone who has completed this port -- Joe T. Hall AT&T Bell Laboratories 708-713-1237 att!ihlpf!pax From icon-group-sender Fri Nov 19 09:12:26 1993 Received: by cheltenham.cs.arizona.edu; Fri, 19 Nov 1993 09:21:13 MST Date: Fri, 19 Nov 93 09:12:26 CST From: wmitchel@glenqcy.glenayre.com (William H. Mitchell) Message-Id: <9311191512.AA08512@faure.glenqcy.glenayre.com> To: icon-group@cs.arizona.edu Subject: Icon in Internet programming contest Status: R Errors-To: icon-group-errors@cs.arizona.edu Were there many notable Icon showings in last night's Internet programming contest? I know that Gregg Townsend of the U of Arizona finished 5th (solved four) in division II using Icon exclusively. Did anybody else rack up a bunch of problems with Icon? From icon-group-sender Tue Nov 23 06:28:04 1993 Received: by cheltenham.cs.arizona.edu; Tue, 23 Nov 1993 08:29:05 MST Date: Tue, 23 Nov 1993 06:28:04 -0600 (CST) From: Chris Tenaglia - 257-8765 Subject: Xfarb for Thanksgiving To: icon-group@cs.arizona.edu Message-Id: <01H5N8C9ZBJ68WW9FP@mis.mcw.edu> Organization: Medical College of Wisconsin (Milwaukee, WI) X-Vms-To: IN%"icon-group@cs.arizona.edu" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Status: R Errors-To: icon-group-errors@cs.arizona.edu It's probably already been done, but I thought I'd post my version of farb ported to X as my Thanksgiving project. It uses colors, so I don't know how it will work on monochrome. After running it a while I noticed that it is kind of annoying. It seems to like popping message boxes on the pointer (shifting the focus), or covering something you happen to typing. Oh well! Chris Tenaglia (System Manager) | "The past explained, Medical College of Wisconsin | the future fortold, 8701 W. Watertown Plank Rd. | the present largely appologized for." Milwaukee, WI 53226 | Organon to The Doctor (414)257-8765 | tenaglia@mis.mcw.edu ############################################################################ # # File: xfarb.icn # # Subject: Program to generate Farberisms # # Author: Ralph E. Griswold # X-ercized by Chris D. Tenaglia # # Date: June 10, 1988 # Updated: November 11, 1993 # ########################################################################### # # Dave Farber, co-author of the original SNOBOL programming # language, is noted for his creative use of the English language. # Hence the terms ``farberisms'' and ``to farberate''. This pro- # gram produces a randomly selected farberism. # # Notes: Not all of the farberisms contained in this program were # uttered by the master himself; others have learned to emulate # him. A few of the farberisms may be objectionable to some per- # sons. ``I wouldn't marry her with a twenty-foot pole.'' # ############################################################################ # # Program note: # # This program is organized into several procedures to avoid overflowing # the default table sizes in the Icon translator and linker. # ############################################################################ procedure main(arg) local count &random := map(&clock,":","0") count := integer(arg[1]) | 1 every xwrite(|??[farb1(),farb2(),farb3(),farb4()]) \ count end procedure xwrite(str) static colors initial colors := ["red","orange","yellow","green","blue","white","black"] scale:=6 bg := ?colors repeat { fg := ?colors (fg == bg) | break } geom := scale*(*str+5) || "x" || scale*4 || "+" || ?512 || "+" || ?768 window := open("XFARBERIZER","x","geometry="||geom, "bg="||bg,"fg="||fg) XAttrib(window,"drawop=reverse") XDrawString(window,6,12,str) XSync(window) delay(10000) close(window) end procedure parse(line,delims) static chars chars := &cset -- delims tokens := [] line ? while tab(upto(chars)) do put(tokens,tab(many(chars))) return tokens end procedure farb1() return [ "I enjoy his smiling continence.", "Picasso wasn't born in a day.", "I'll be there with spades on.", "Beware a Trojan bearing a horse.", "A hand in the bush is worth two anywhere else.", "All the lemmings are going home to roost.", "Anybody who marries her would stand out like a sore thumb.", "Before they made him they broke the mold.", "He's casting a red herring on the face of the water.", "Clean up or fly right.", "Come down off your charlie horse.", "Don't burn your bridges until you come to them.", "Don't count your chickens until the barn door is closed.", "Don't do anything I wouldn't do standing up in a hammock.", "Don't get your eye out of joint.", "Don't just stand there like a sitting duck.", "Don't look a mixed bag in the mouth.", "Don't look at me in that tone of voice.", "Don't make a molehill out of a can of beans.", "Don't make a tempest out of a teapot." ] end procedure farb2() return [ "Don't upset the apple pie.", "Every cloud has a blue horizon.", "She's faster than the naked eye.", "Feather your den with somebody else's nest.", "From here on up, it's down hill all the way.", "Go fly your little red wagon somewhere else.", "Half a worm is better than none.", "He doesn't know which side his head is buttered on.", "He has feet of molasses.", "He hit the nose right on the head.", "He knows which side his pocketbook is buttered on.", "He smokes like a fish.", "He was hoisted by a skyhook on his own petard!", "He was putrified with fright.", "He would forget his head if it weren't screwed up.", "He's as happy as a pig at high tide.", "He's been living off his laurels for years.", "He's got a rat's nest by the tail.", "He's got four sheets in the wind.", "He's letting ground grow under his feet.", "He's lying through his britches.", "He's procrastinating like a bandit.", "He's reached the crescent of his success.", "He's so far above me I can't reach his bootstraps.", "He's too smart for his own bootstraps.", "His foot is in his mouth up to his ear.", "History is just a repetition of the past.", "I apologize on cringed knees.", "I don't know which dagger to clothe it in.", "I hear the handwriting on the wall.", "I wouldn't marry her with a twenty-foot pole.", "I'll procrastinate when I get around to it.", "I'm going to throw myself into the teeth of the gamut.", "I'm parked somewhere in the boondoggles." ] end procedure farb3() return [ "I'm walking on cloud nine.", "I've got to put my duff to the grindstone.", "I've had it up to the hilt.", "If Calvin Coolidge were alive today, he'd turn over in his grave.", "If the onus fits, wear it.", "Is he an Amazon!", "It fills a well-needed gap.", "It is better to have tried and failed than never to have failed at all.", "It looks like it's going to go on ad infinitum for a while.", "It sounds like roses to my ears.", "It's a caterpillar in pig's clothing.", "It's a fiat accompli.", "It's a fool's paradise wrapped in sheep's clothing.", "It's a monkey wrench in your ointment.", "It's a new high in lows.", "It's bouncing like a greased pig.", "It's enough to make you want to rot your socks.", "It's like talking to a needle in a haystack.", "It's like trying to light a fire under a lead camel.", "It's not his bag of tea.", "It's so unbelieveable you wouldn't believe it.", "Just because it's there, you don't have to mount it.", "Keep your ear peeled!", "Let's not drag any more dead herrings across the garden path.", "Let's skin another can of worms.", "Look at the camera and say `bird'.", "Look before you turn the other cheek.", "Men, women, and children first!", "Necessity is the mother of strange bedfellows.", "Never feed a hungry dog an empty loaf of bread.", "No rocks grow on Charlie.", "No sooner said, the better.", "Nobody could fill his socks.", "Nobody is going to give you the world in a saucer.", "Nobody marches with the same drummer.", "Not by the foggiest stretch of the imagination!", "Not in a cocked hat, you don't!", "People in glass houses shouldn't call the kettle black.", "Put it on the back of the stove and let it simper." ] end procedure farb4() return [ "Put the onus on the other foot.", "Rome wasn't built on good intentions alone.", "She has eyes like two holes in a burnt blanket.", "She's a virgin who has never been defoliated.", "She's trying to feather her own bush.", "Somebody's flubbing his dub.", "It's steel wool and a yard wide.", "Straighten up or fly right.", "Strange bedfellows flock together.", "That's a bird of a different color.", "That's a horse of a different feather.", "That's a sight for deaf ears.", "That's the way the old ball game bounces.", "The die has been cast on the face of the waters.", "The early bird will find his can of worms.", "The foot that rocks the cradle is usually in the mouth.", "The onus is on the other foot.", "The whole thing is a hairy potpourri.", "There are enough cooks in the pot already.", "There's a dark cloud on every rainbow's horizon.", "There's a flaw in the ointment.", "There's going to be hell and high water to pay.", "They don't stand a teabag's chance in hell.", "They sure dipsied his doodle.", "This ivory tower we're living in is a glass house.", "Time and tide strike but once." ] end From icon-group-sender Tue Nov 23 10:40:57 1993 Received: by cheltenham.cs.arizona.edu; Tue, 23 Nov 1993 12:12:20 MST Date: Tue, 23 Nov 93 10:40:57 MST From: cliff (Cliff Hathaway) Message-Id: <9311231740.AA12112@javelina.cs.arizona.edu> To: icon-group Subject: Solaris 2.x config available Content-Length: 438 Status: R Errors-To: icon-group-errors@cs.arizona.edu There is a new distribution of Icon version 8.10 for Unix, available via anonymous ftp from ftp.cs.arizona.edu, in /icon/packages/unix/unix_tar.Z. This distribution contains a configuration for Solaris 2.2, using the Sun C compiler, /opt/SUNWspro/bin/cc. It also contains a complete configuration for Sun OpenWindows under SunOS 4.1.x, courtesy of Yarko Tymciurak. It also contains a config- uration for CenterLine C under Solaris 2.x. From icon-group-sender Sun Nov 21 07:34:22 1993 Received: by cheltenham.cs.arizona.edu; Tue, 23 Nov 1993 18:18:19 MST Date: 21 Nov 93 07:34:22 GMT From: noc.near.net!news.delphi.com!usenet@uunet.uu.net (Will Mengarini) Organization: Delphi Internet Subject: Re: dos executables from icon Message-Id: <931121.09262.MENGARINI@delphi.com> References: <93312.000307U47041@uicvm.uic.edu>, <931114.21573.MENGARINI@delphi.com>, Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu That's worth knowing; thanks. However, I only have Borland C++ v3.1, which is limited to 16 bits; that's why I'm planning to use Phar Lap 286. I have the Borland ads for their new v4.0 (who doesn't?), but I suspect Borland shoved this out the door to compete with Symantec, & the underlying compiler is probably even buggier than v3.1 (which is very buggy). I'll keep in mind that a 32-bit version is available, tho, since it'll probably be less than another year before a reliable 32-bit Borland C++ is available. From icon-group-sender Sun Nov 21 07:35:36 1993 Received: by cheltenham.cs.arizona.edu; Tue, 23 Nov 1993 18:19:02 MST Date: 21 Nov 93 07:35:36 GMT From: noc.near.net!news.delphi.com!usenet@uunet.uu.net (Will Mengarini) Organization: Delphi Internet Subject: Re: dos executables from icon Message-Id: <931121.09336.MENGARINI@delphi.com> References: <93312.000307U47041@uicvm.uic.edu>, <931114.21573.MENGARINI@delphi.com>, Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu My next post has 889 lines. It's mostly source code for a patch to MS-DOS Icon v8.8 allowing it to produce .Exe files. From icon-group-sender Sun Nov 21 07:54:22 1993 Received: by cheltenham.cs.arizona.edu; Tue, 23 Nov 1993 18:19:26 MST Date: 21 Nov 93 07:54:22 GMT From: noc.near.net!news.delphi.com!usenet@uunet.uu.net (Will Mengarini) Organization: Delphi Internet Subject: Re: dos executables from icon Message-Id: <931121.10462.MENGARINI@delphi.com> References: <93312.000307U47041@uicvm.uic.edu>, <931114.21573.MENGARINI@delphi.com>, Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu This is the source code of a method for producing executable MS-DOS *.Exe files from Icon programs using the Icon interpretive system (IconT & IconX). It should be Makeable with 16-bit or 32-bit compilers on any computer that can Make the Icon interpretive system itself. This is a modification of the source code for Version 8.8 of Icon for MS-DOS. That distribution's *.LZH archives have timestamps 3/22/93 03:17..03:19. It was developed under Borland C++ v3.1 in Sep 93, & has been in regular use since then for production of directly-executable MS-DOS Icon programs. IconT usage remains unchanged except for 2 things. >> There is now a -E option, which tells IconT to produce a .Exe file instead of a .Icx file. (Case is significant; the -e option redirects standard error.) All the other options still work the same way: the -c option still works to produce linkable ucode, & if both -c & -E are omitted a .Icx file is produced. >> When the -E option is used with IconT, the file IconDOS.Exe must be in the same directory as IconT.Exe. The .Exe file that IconT outputs can then be executed as a command at the DOS prompt or from inside a batch job, just like any other .Exe file. I/O redirection works normally. However, altho IconX.Exe need no longer be invoked as a command to run the new Icon program--the new Icon program itself is the command--IconX.Exe must be in one of the directories on the DOS Path. This is what is needed to install this patch. >> You must already have set up the directories & files for Making the Icon interpretive system (IconT & IconX). How to do this is described in the document IPD205.Doc, timestamp 11/19/92 16:13, which comes with the Icon v8.8 for MS-DOS distribution. When I refer to files in this article, I'll use absolute paths that will be correct iff you installed the Icon hierarchy with \Icon as its root; this is also the assumption made in IPD205.Doc. In both cases, that's just illustrative; what really matters is the relative path below \Icon (or wherever). >> You must have Maked & installed a working IconT & IconX as described in sections 3 & 4 of IPD205.Doc. Note that the Icon distribution comes with its own Make.Exe to run its Makefiles, & those Makefiles are not compatible with the Borland C++ 3.1 Make.Exe. When you run an Icon Make, you need to cause the directory containing Icon's Make.Exe to precede the directory containing your C compiler's Make.Exe on the DOS Path, even tho you'll probably also require that your C compiler's directory be on Path. >> You must modify the following 7 files in the Icon hierarchy: \Icon\Src\h\Config.h \Icon\Src\IconT\Globals.h \Icon\Src\IconT\LCode.c \Icon\Src\IconT\Link.c \Icon\Src\IconT\TMain.c \Icon\Src\Runtime\Init.r \Icon\Src\Runtime\Init.r The list of modifications takes up most of the rest of this article. >> You must then reMake both IconT & IconX by following steps 1-3 on page 6 of IPD205.Doc. >> You must create the following new file in the Icon hierarchy: \Icon\Src\Runtime\IconDOS.c Its text is at the end of this article. >> You must compile that IconDOS.c to produce IconDOS.Exe. How you do that depends on your particular compiler, but since IconDOS.c is pure vanilla C, whatever compiler options you used for the other C source files in the Icon interpreter system should work, except that you should use the Small memory model instead of Large. (Don't use the Tiny model, which produces a .Com file--it won't work.) If you have an optimizing C compiler, I recommend fully optimizing for size. Omit debugging information; by the time you produce an executable .Exe, that information would have been clobbered anyway. IconDOS.Exe is not intended to be a runnable program, but since it looks to MS-DOS like one, its behavior when you run it can test that you compiled it correctly. It should produce an error message like this: error in startup code C:\ICON\BIN\ICONDOS.EXE: can't read interpreter file header Anything else (except a different path) means the compilation failed. IconDOS.Exe must be compiled into the directory that contains IconT.Exe, or moved into that directory after compilation. Intermediate files from the compilation, like IconDOS.{Obj,Map}, can be deleted. After you've done all of this, the -E option to IconT should work. In the following patch descriptions, a form like this ======Cut Here: \Dir\Name.Ext [replace 6-9]====== line1 line2 line3 --------------------Cut Here--------------------- means that in the file \Dir\Name.Ext, the 4 lines numbered 6-9 are to be deleted, then replaced by the 3 lines line1 line2 line3 shown explicitly. Everything shown between the "Cut Here" lines is to be inserted as is into the file; only the "Cut Here" lines are metadata. The form ======Cut Here: \Dir\Name.Ext [precede 88]====== line4 line5 --------------------Cut Here--------------------- is similar, but nothing is to be deleted; the lines between the "Cut Here" lines are just to be inserted before line 88. ============Cut Here: \Icon\Src\h\Config.h [replace 797-833]========== #ifndef Options #ifndef Xver #if ARM || UNIX #define Options "C:LS:Tce:f:mn:o:p:r:stuv:x" #else /* ARM || UNIX */ #if MSDOS #define Options "C:ELS:Tce:f:n:o:p:r:stuv:x" #else /* MSDOS */ #define Options "C:LS:Tce:f:n:o:p:r:stuv:x" #endif /* MSDOS */ #endif /* ARM || UNIX */ #else /* Xver */ xver(config.3) #endif /* Xver */ #endif /* Options */ #ifndef CUsage #if UNIX #define CUsage "[-C C-comp] [-T] [-c] [-f{adelns}] [-m] [-n{acest}]\n\ [-o ofile] [-p C-opts] [-r runtime] [-s] [-t] [-u] [-v i]" #else /* UNIX */ #define CUsage "[-C C-comp] [-T] [-c] [-f{adelns}] [-n{acest}]\n\ [-o ofile] [-p C-opts] [-r runtime] [-s] [-t] [-u] [-v i]" #endif /* UNIX */ #endif /* CUsage */ #ifndef TUsage #ifndef Xver #if ARM || UNIX #define TUsage "[-cmstu] [-e efile] [-o ofile]" #else /* ARM || UNIX */ #if MVS || VM #define TUsage "<-cstu> <-e efile> <-o ofile>" #else /* MVS || VM */ #if MSDOS #define TUsage "[-cstuE] [-e efile] [-o ofile]" #else /* MSDOS */ #define TUsage "[-cstu] [-e efile] [-o ofile]" #endif /* MSDOS */ #endif /* MVS || VM */ #endif /* ARM || UNIX */ #else /* Xver */ xver(config.4) #endif /* Xver */ #endif /* TUsage */ -----------------------Cut Here--------------------- =========Cut Here: \Icon\Src\IconT\Globals.h [precede 47]======== #if MSDOS Global int makeExe Init(0); /* -E: Create .Exe instead of .Icx */ Global long fileOffsetOfStuffThatGoesInICX Init(0); /* Remains 0 if -E not used */ /* set in link.c, used in lcode.c */ #endif -----------------------Cut Here--------------------- ==========Cut Here: \Icon\Src\Runtime\Init.r [replace 273-331]======== #if MSDOS int thisIsAnExeFile = 0; char bytesThatBeginEveryExe[2] = {0,0}; unsigned originalExeBytesMod512, originalExePages; unsigned long originalExeBytes; #endif /* MSDOS */ if (!name) error(name, "no interpreter file supplied"); /* * Try adding the suffix if the file name doesn't end in it, * unless this is a MSDOS .Exe file (which already has the ".Exe"). */ n = strlen(name); #if MSDOS if (n >= 4 && !stricmp(".Exe", name + n - 4)) { thisIsAnExeFile = 1; fname = pathOpen(name, ReadBinary); /* * IconDOS's code for calling IconX from an .Exe passes IconX the * full path of the .Exe, so using pathOpen() seems redundant & * potentially inefficient. However, pathOpen() first checks for a * complete path, & if one is present, doesn't search Path; & since * MS-DOS has a limited line length, it'd be possible for IconDOS * to check whether the full path will fit, & if not, use only the * name. The only price for this additional robustness would be * the time pathOpen() spends checking for a path, which is trivial. */ } else { #endif /* MSDOS */ if (n <= 4 || (strcmp(name+n-4,IcodeSuffix) != 0) && strcmp(name+n-4,IcodeASuffix) != 0) { char tname[100]; if ((int)strlen(name) + 5 > 100) error(name, "icode file name too long"); strcpy(tname,name); #if MVS { /*Begin MVS block*/ char *p; if (p = index(name, '(')) { tname[p-name] = '\0'; } #endif /* MVS */ strcat(tname,IcodeSuffix); #if MVS if (p) strcat(tname,p); } /*End MVS block*/ #endif /* MVS */ #if MSDOS || OS2 fname = pathOpen(tname,ReadBinary); /* try to find path */ #else /* MSDOS || OS2 */ fname = fopen(tname, ReadBinary); #endif /* MSDOS || OS2 */ } /* end if (n <= 4 || etc for 2 lines */ if (fname == NULL) /* try the name as given */ #if MSDOS || OS2 fname = pathOpen(name, ReadBinary); #else /* MSDOS || OS2 */ fname = fopen(name, ReadBinary); #endif /* MSDOS || OS2 */ #if MSDOS } /* end if (n >= 4 && !stricmp(".Exe", name + n - 4)) */ #endif if (fname == NULL) return NULL; #ifdef Xver xver(imain.9) #endif /* Xver */ { static char errmsg[] = "can't read interpreter file header"; static char exe_errmsg[] = "can't read MS-DOS .Exe header"; #ifdef Header #if MSDOS #error deliberate syntax error /* * The MSDOS .Exe-handling code assumes & requires that the executable * .Exe be followed immediately by the icode itself (actually header.h). * This is because the following Header fseek() is relative to the * beginning of the file, which in a .Exe is the beginning of the * executable code, not the beginning of some Icon thing; & I can't * check & fix all the Header-handling logic because hdr.h wasn't * included with my MS-DOS distribution so I don't even know what it does, * let alone how to keep from breaking it. We're safe as long as * Header & MSDOS are disjoint. */ #endif /* MSDOS */ if (fseek(fname, (long)MaxHeader, 0) == -1) error(name, errmsg); #endif /* Header */ #if MSDOS if (thisIsAnExeFile) { fread (&bytesThatBeginEveryExe, sizeof bytesThatBeginEveryExe, 1, fname); if (bytesThatBeginEveryExe[0] != 'M' || bytesThatBeginEveryExe[1] != 'Z') error(name, exe_errmsg); fread (&originalExeBytesMod512, sizeof originalExeBytesMod512, 1, fname); fread (&originalExePages, sizeof originalExePages, 1, fname); originalExeBytes = (originalExePages - 1)*512 + originalExeBytesMod512; if (fseek(fname, originalExeBytes, 0)) error(name, errmsg); if (ferror(fname) || feof(fname) || !originalExeBytes) error(name, exe_errmsg); } #endif /* MSDOS */ -----------------------Cut Here--------------------- Next file is changed in 2 places. Second change is stated in terms of lines in v8.8 file ("old") and equivalently of lines in that file after first change ("new"). ==========Cut Here: \Icon\Src\IconT\LCode.c [precede 47]========= #if MSDOS extern long fileOffsetOfStuffThatGoesInICX; /* defined in Globals.h, set in link.c, used below */ #endif /* MSDOS */ ====Cut Here: \Icon\Src\IconT\LCode.c [replace old 1164-6 = new 1169-71]==== #else #if MSDOS fseek(outfile, fileOffsetOfStuffThatGoesInICX, 0); #else fseek(outfile, 0L, 0); #endif /* MSDOS */ #endif /* MVS */ -----------------------Cut Here--------------------- Next file is changed in 2 places. Second change is stated in terms of lines in v8.8 file ("old") and equivalently of lines in that file after first change ("new"). ===========Cut Here: \Icon\Src\IconT\Link.c [precede 75]========= #ifdef MSDOS extern char pathToIconDOS[]; #endif /* MSDOS */ ========Cut Here: \Icon\Src\IconT\Link.c [precede old 227 = new 231]====== #ifdef MSDOS /* * This prepends IconDOS.Exe to outfile, so it'll be executable. * * I don't know what that #if Header stuff was about since my MSDOS * distribution didn't include "hdr.h", but it looks very similar to * what I'm doing, so I'll put my stuff here, & if somebody who * understands all the multi-operating-system porting thinks my code could * be folded into it, having it here should make it easy. */ if (makeExe) { FILE *fIconDOS = fopen (pathToIconDOS, "rb"); char bytesThatBeginEveryExe[2] = {0,0}, oneChar; unsigned originalExeBytesMod512, originalExePages; unsigned long originalExeBytes, byteCounter; if (!fIconDOS) quit("unable to find IconDOS.Exe in same dir as IconT"); if (setvbuf(fIconDOS, 0, _IOFBF, 4096)) if (setvbuf(fIconDOS, 0, _IOFBF, 128)) quit("setvbuf() failure"); fread (&bytesThatBeginEveryExe, 2, 1, fIconDOS); if (bytesThatBeginEveryExe[0] != 'M' || bytesThatBeginEveryExe[1] != 'Z') quit("IconDOS header is corrupt"); fread (&originalExeBytesMod512, sizeof originalExeBytesMod512, 1, fIconDOS); fread (&originalExePages, sizeof originalExePages, 1, fIconDOS); originalExeBytes = (originalExePages - 1)*512 + originalExeBytesMod512; if (ferror(fIconDOS) || feof(fIconDOS) || !originalExeBytes) quit("IconDOS header is corrupt"); fseek (fIconDOS, 0, 0); for (byteCounter = 0; byteCounter < originalExeBytes; byteCounter++) { oneChar = fgetc (fIconDOS); if (ferror(fIconDOS) || feof(fIconDOS) || ferror(outfile)) quit("Error copying IconDOS.Exe"); fputc (oneChar, outfile); } fclose (fIconDOS); fileOffsetOfStuffThatGoesInICX = ftell (outfile); } #endif /* MSDOS */ -----------------------Cut Here--------------------- ==========Cut Here: \Icon\Src\IconT\TMain.c [replace 70-509]========= #ifdef MSDOS char pathToIconDOS[129]; #endif /* MSDOS */ * The following code is operating-system dependent [@tmain.02]. Definition * of refpath. */ #if PORT /* something is needed */ Deliberate Syntax Error #endif /* PORT */ #if UNIX || AMIGA || ATARI_ST || MACINTOSH || MSDOS || MVS || OS2 || VM char *refpath = RefPath; #endif /* UNIX ... */ #if VMS char *refpath = "ICON_BIN:"; #endif /* VMS */ * End of operating-system specific code. */ char *iconxloc; * getopt() variables */ extern int optindex; /* index into parent argv vector */ extern int optopt; /* character checked for validity */ extern char *optarg; /* argument associated with option */ * main program */ novalue main(argc,argv) int argc; char **argv; { int nolink = 0; /* suppress linking? */ int errors = 0; /* translator and linker errors */ char **tfiles, **tptr; /* list of files to translate */ char **lfiles, **lptr; /* list of files to link */ char **rfiles, **rptr; /* list of files to remove */ char *efile = NULL; /* stderr file */ char buf[MaxFileName]; /* file name construction buffer */ int c, n; struct fileparts *fp; #if AMIGA #if AZTEC_C struct Process *FindTask(); struct Process *Process = FindTask(0L); ULONG stacksize = *((ULONG *)Process->pr_ReturnAddr); if (stacksize < ICONTMINSTACK) { fprintf(stderr,"Icont needs \"stack %d\" to run\n",ICONTMINSTACK); exit(-1); } #endif /* AZTEC_C */ #endif /* AMIGA */ #if MACINTOSH #if MPW InitCursorCtl(NULL); SortOptions(argv); #endif /* MPW */ #endif /* MACINTOSH */ iconxloc = (char *)alloc((unsigned)strlen(refpath) + 6); strcpy(iconxloc, refpath); strcat(iconxloc, "iconx"); if (strlen(patchpath)>18) iconxloc = patchpath+18; /* * Process options. */ while ((c = getopt(argc,argv,Options)) != EOF) switch (c) { case 'C': /* Ignore: compiler only */ break; #ifdef MSDOS case 'E': /* -E */ makeExe = 1; break; #endif #ifdef Xver xver(tmain.1) #endif /* Xver */ case 'L': /* -L: enable linker debugging */ #ifdef DeBugLinker Dflag = 1; #endif /* DeBugLinker */ break; case 'S': /* -S */ fprintf(stderr, "Warning, -S option is obsolete\n"); break; case 'c': /* -c: compile only (no linking) */ nolink = 1; break; case 'e': /* -e file: redirect stderr */ efile = optarg; break; case 'f': /* Ignore: compiler only */ break; case 'm': /* -m: preprocess using m4(1) [UNIX] */ m4pre = 1; break; case 'n': /* Ignore: compiler only */ break; case 'o': /* -o file: name output file */ ofile = optarg; break; case 'p': /* -p path: iconx path [ATARI] */ #if ATARI_ST patharg = optarg; #endif /* ATARI_ST */ break; case 'r': /* Ignore: compiler only */ break; case 's': /* -s: suppress informative messages */ silent = 1; break; case 't': /* -t: turn on procedure tracing */ trace = -1; break; case 'u': /* -u: warn about undeclared ids */ uwarn = 1; break; case 'v': /* Ignore: compiler only */ break; default: case 'x': /* -x illegal until after file list */ usage(); } #ifdef MSDOS /* * Define pathToIconDOS as a global accessible from inside * separately-compiled compilation units. */ if( makeExe ){ char *pathCursor; strcpy (pathToIconDOS, argv[0]); pathCursor = strrchr (pathToIconDOS, '\\'); if (!pathCursor) { fprintf (stderr, "Can't understand what directory IconT was run from.\n"); exit(ErrorExit); } strcpy (++pathCursor, "IconDOS.Exe"); } #endif /* MSDOS */ /* * Allocate space for lists of file names. */ n = argc - optindex + 1; tptr = tfiles = (char **)alloc((unsigned int)(n * sizeof(char *))); lptr = lfiles = (char **)alloc((unsigned int)(n * sizeof(char *))); rptr = rfiles = (char **)alloc((unsigned int)(2 * n * sizeof(char *))); /* * Scan file name arguments. */ while (optindex < argc) { if (strcmp(argv[optindex],"-x") == 0) /* stop at -x */ break; else if (strcmp(argv[optindex],"-") == 0) { #if ARM /* Different file naming, so we need a different strategy... */ *tptr++ = "-"; /* Use makename(), pretending we had an input file named "Stdin" */ makename(buf,TargetDir,"Stdin",U1Suffix); *lptr++ = *rptr++ = salloc(buf); /* link & remove .u1 */ makename(buf,TargetDir,"Stdin",U2Suffix); *rptr++ = salloc(buf); /* also remove .u2 */ #else /* ARM */ *tptr++ = "-"; /* "-" means standard input */ *lptr++ = *rptr++ = "stdin.u1"; *rptr++ = "stdin.u2"; #endif /* ARM */ } else { fp = fparse(argv[optindex]); /* parse file name */ if (*fp->ext == '\0' || smatch(fp->ext, SourceSuffix)) { makename(buf,SourceDir,argv[optindex], SourceSuffix); #if VMS strcat(buf, fp->version); #endif /* VMS */ *tptr++ = salloc(buf); /* translate the .icn file */ makename(buf,TargetDir,argv[optindex],U1Suffix); *lptr++ = *rptr++ = salloc(buf); /* link & remove .u1 */ makename(buf,TargetDir,argv[optindex],U2Suffix); *rptr++ = salloc(buf); /* also remove .u2 */ } else if (smatch(fp->ext,U1Suffix) || smatch(fp->ext,U2Suffix) || smatch(fp->ext,USuffix)) { makename(buf,TargetDir,argv[optindex],U1Suffix); *lptr++ = salloc(buf); } else quitf("bad argument %s",argv[optindex]); } optindex++; } *tptr = *lptr = *rptr = NULL; /* terminate filename lists */ if (lptr == lfiles) usage(); /* error -- no files named */ /* * Round hash table sizes to next power of two, and set masks for hashing. */ lchsize = round2(lchsize); cmask = lchsize - 1; fhsize = round2(fhsize); fmask = fhsize - 1; ghsize = round2(ghsize); gmask = ghsize - 1; ihsize = round2(ihsize); imask = ihsize - 1; lhsize = round2(lhsize); lmask = lhsize - 1; /* * Translate .icn files to make .u1 and .u2 files. */ if (tptr > tfiles) { if (!silent) report("Translating"); errors = trans(tfiles); if (errors > 0) /* exit if errors seen */ exit(ErrorExit); } /* * Link .u1 and .u2 files to make an executable. */ if (nolink) { /* exit if no linking wanted */ #if MACINTOSH #if MPW /* * Set type of translator output ucode (.u) files * to 'TEXT', so they can be easily viewed by editors. */ { char **p; void setfile(); for (p = rfiles; *p; ++p) setfile(*p,'TEXT','icon'); } #endif /* MPW */ #endif /* MACINTOSH */ exit(NormalExit); } #if MSDOS if (ofile == NULL) { /* if no -o file, synthesize a name */ ofile = salloc(makename(buf,TargetDir,lfiles[0], makeExe ? ".Exe" : IcodeSuffix)); } else { /* add extension if necessary */ fp = fparse(ofile); if (*fp->ext == '\0' && *IcodeSuffix != '\0') /* if no ext given */ ofile = salloc(makename(buf,NULL,ofile, makeExe ? ".Exe" : IcodeSuffix)); } #else /* MSDOS */ if (ofile == NULL) { /* if no -o file, synthesize a name */ ofile = salloc(makename(buf,TargetDir,lfiles[0],IcodeSuffix)); } else { /* add extension if necessary */ fp = fparse(ofile); if (*fp->ext == '\0' && *IcodeSuffix != '\0') /* if no ext given */ ofile = salloc(makename(buf,NULL,ofile,IcodeSuffix)); } #endif /* MSDOS */ if (!silent) report("Linking"); errors = ilink(lfiles,ofile); /* link .u files to make icode file */ /* * Finish by removing intermediate files. * Execute the linked program if so requested and if there were no errors. */ #if MACINTOSH #if MPW /* Set file type to TEXT so it will be executable as a script. */ setfile(ofile,'TEXT','icon'); #endif /* MPW */ #endif /* MACINTOSH */ rmfiles(rfiles); /* remove intermediate files */ if (errors > 0) { /* exit if linker errors seen */ unlink(ofile); exit(ErrorExit); } #if !(MACINTOSH && MPW) if (optindex < argc) { if (!silent) report("Executing"); execute (ofile, efile, argv+optindex+1); } #endif /* !(MACINTOSH && MPW) */ exit(NormalExit); } * execute - execute iconx to run the icon program */ static novalue execute(ofile,efile,args) char *ofile, *efile, **args; { #if !(MACINTOSH && MPW) int n; char **argv, **p; for (n = 0; args[n] != NULL; n++) /* count arguments */ ; p = argv = (char **)alloc((unsigned int)((n + 5) * sizeof(char *))); *p++ = iconxloc; /* set iconx pathname */ if (efile != NULL) { /* if -e given, copy it */ *p++ = "-e"; *p++ = efile; } *p++ = ofile; /* pass icode file name */ #if AMIGA && LATTICE *p = *args; while (*p++) { *p = *args; args++; } #else /* AMIGA && LATTICE */ while (*p++ = *args++) /* copy args into argument vector */ ; #endif /* AMIGA && LATTICE */ *p = NULL; * The following code is operating-system dependent [@tmain.03]. It calls * iconx on the way out. */ #if PORT /* something is needed */ Deliberate Syntax Error #endif /* PORT */ #if AMIGA #if AZTEC_C execvp(iconxloc,argv); return; #endif /* AZTEC_C */ #if LATTICE { struct ProcID procid; if (forkv(iconxloc,argv,NULL,&procid) == 0) { wait(&procid); return; } } #endif /* LATTICE */ #endif /* AMIGA */ #if ARM { int i = 7 + strlen(iconxloc); int j; char *s; char buffer[255]; extern int armquote(char *, char **); sprintf(buffer, "Chain:%s ", iconxloc); for (p = argv + 1; *p; ++p) { j = armquote(*p, &s); if (j == -1 || i + j >= 255) { fprintf(stderr, "Cannot execute: command line too long"); fflush(stderr); return; } strcpy(buffer + i, s); i += j; buffer[i] = ' '; } buffer[i] = '\0'; system(buffer); } #endif /* ARM */ #if ATARI_ST || MACINTOSH fprintf(stderr,"-x not supported\n"); fflush(stderr); #endif /* ATARI_ST || ... */ #if MSDOS /* * No special handling is needed for an .Exe, since IconX recognizes * it from the extension & from internal .Exe header data. */ #if MICROSOFT || TURBO execvp(iconxloc,argv); /* execute with path search */ #endif /* MICROSOFT || ... */ #if INTEL_386 || ZTC_386 || HIGHC_386 || WATCOM fprintf(stderr,"-x not supported\n"); fflush(stderr); #endif /* INTEL_386 || ... */ #endif /* MSDOS */ #if MVS || VM #if SASC exit(sysexec(iconxloc, argv)); #endif /* SASC */ fprintf(stderr,"-x not supported\n"); fflush(stderr); #endif /* MVS || VM */ #if OS2 execvp(iconxloc,argv); /* execute with path search */ #endif /* OS2 */ #if UNIX /* * If an ICONX environment variable is defined, use that. * If not, first try the predefined path, then search $PATH via execvp. */ if ((argv[0] = getenv("ICONX")) != NULL && argv[0][0] != '\0') { execv(argv[0], argv); /* exec file specified by $ICONX */ quitf("cannot execute $ICONX (%s)", argv[0]); } #ifdef HardWiredPaths #ifdef CRAY argv[0] = "iconx"; execv(iconxloc, argv); #else /* CRAY */ argv[0] = iconxloc; /* try predefined file */ execv(argv[0], argv); #endif /* CRAY */ #endif /* HardWiredPaths */ argv[0] = "iconx"; execvp(argv[0], argv); /* if no iconxloc, search path for "iconx" */ #ifdef HardWiredPaths quitf("cannot run %s", iconxloc); #else /* HardWiredPaths */ quitf("cannot find iconx", ""); #endif /* HardWiredPaths */ #endif /* UNIX */ #if VMS execv(iconxloc,argv); #endif /* VMS */ * End of operating-system specific code. */ -----------------------Cut Here--------------------- ==========Cut Here: \Icon\Src\Runtime\IconDOS.c [create]======== * IconDOS.c -- Header for MS-DOS Icon *.Exe (executable) file */ #include #include #include #include int main( int argc, char **argv ){ char *argsToIconX[129], **argsToIconXCursor, **argvCursor; argsToIconXCursor = argsToIconX; argvCursor = argv; *argsToIconXCursor++ = "IconX"; while( argc-- ) *argsToIconXCursor++ = *argvCursor++; *argsToIconXCursor++ = 0; ; execvp( "IconX", argsToIconX ); perror( "Couldn't execvp( \"IconX\", ... )" ); ; return 250; } -----------------------Cut Here--------------------- My office computer doesn't have a modem, & I usually sleep at the office for a week at a time, so I'll be slow to respond to e-mail & slower to snailmail. I try to read comp.lang.icon weekly, but sometimes I miss it. I've had 2 reports of e-mail messages getting lost, & snailmail is also unreliable. Please don't misconstrue these communications difficulties as signs of disinterest; I'll try to respond to anyone who needs help getting this patch installed, or who reports bugs or suggests enhancements. Will Mengarini; 4739 University Wy NE #1001; Seattle WA 98105-4495 mengarini@delphi.com 206\632-4130 From icon-group-sender Wed Nov 17 20:52:27 1993 Received: by cheltenham.cs.arizona.edu; Fri, 26 Nov 1993 10:42:12 MST Date: 17 Nov 93 20:52:27 GMT From: walter!news@uunet.uu.net (Darren New) Organization: Bellcore Subject: X-windows Message-Id: Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Is there any documentation on how to access X-windows functionality from ICON? Thanks! -- Darren -- 445 South St/MRE 2E-279/Morristown NJ 07960 USA/(201)829-4833 Delivery of Electronic Multimedia over Networks (DEMON) Also, formal description techniques, programming languages. ``Your fault: Core dumped.'' EFF#846 ``Sometimes, you just have to bite the silver bullet.'' From icon-group-sender Wed Nov 17 04:28:00 1993 Received: by cheltenham.cs.arizona.edu; Fri, 26 Nov 1993 10:43:40 MST Date: 17 Nov 93 04:28:00 GMT From: europa.eng.gtefsd.com!library.ucla.edu!csulb.edu!csus.edu!netcom.com!cas@uunet.uu.net (Charles A. Shartsis) Organization: Netcom Online Communications Services (408-241-9760 login: guest) Subject: Re: dos executables from icon Message-Id: References: <93312.000307U47041@uicvm.uic.edu>, <931114.21573.MENGARINI@delphi.com> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu In article <931114.21573.MENGARINI@delphi.com> Will Mengarini writes: >For my next trick, I want to rebuild Icon{T,X} to run in >protected mode under Phar Lap's 16-bit DOS extender. I wouldn't >be surprised if somebody has done this already; if so, please >post your Make file. I'll try to also integrate my .Exe system >with that, but your Make file will help as a starting point even >if you haven't worked on the .Exe problem. > Icon Version 8.8 for MSDOS 386/486 is available from the Icon project via anonymous ftp (cs.arizona.edu). Its ICONX runs Icon programs in 32-bit protected mode and can access memory above the conventional 1 MB limit. It was compiled using the Intel DOS extender. According to the documentation, the address space can be as large as 4 GB. I don't know if ICONT was built in the same way, however I know that it can handle Icon source modules containing many more symbols than its predecessors could. From icon-group-sender Thu Nov 18 15:51:42 1993 Received: by cheltenham.cs.arizona.edu; Sun, 28 Nov 1993 16:37:18 MST Date: 18 Nov 93 15:51:42 GMT From: walter!news@uunet.uu.net (Darren New) Organization: Bellcore Subject: Window functions Message-Id: Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Is there any documentation available for the &features identified as window functions X Windows I have the doc files available, but I don't want to print out hundreds of pages of Postscript to find the document I'm looking for, in case anyone knows which ipd file it is. Thanks! -- Darren -- 445 South St/MRE 2E-279/Morristown NJ 07960 USA/(201)829-4833 Delivery of Electronic Multimedia over Networks (DEMON) Also, formal description techniques, programming languages. ``Your fault: Core dumped.'' EFF#846 ``Sometimes, you just have to bite the silver bullet.'' From icon-group-sender Sat Nov 27 12:47:03 1993 Received: by cheltenham.cs.arizona.edu; Sun, 28 Nov 1993 16:41:55 MST Date: Sat, 27 Nov 93 12:47:03 CST From: jeffery@ringer.cs.utsa.edu (Clinton L. Jeffery) Message-Id: <9311271847.AA26062@ringer.cs.utsa.edu.sunset> To: icon-group@cs.arizona.edu In-Reply-To: (Darren New's message of 17 Nov 93 20:52:27 GMT Subject: X-windows Content-Length: 706 Status: R Errors-To: icon-group-errors@cs.arizona.edu > Darren New asks: Is there any documentation on how to access X-windows functionality from ICON? [I did not see an answer to this; my apologies if I am repeating someone here.] University of Arizona technical report TR93-9 provides documentation on window systems functionality for Icon that is presently available on X Window and OS/2 Presentation Manager platforms. It is available by anonymous ftp to cs.arizona.edu in directory reports/1993, the file is TR93-09.ps.Z (a compressed postscript file). We are working on additional window system ports, and on more substantial documentation. Clint Jeffery, jeffery@ringer.cs.utsa.edu, cjeffery@cs.arizona.edu The University of Texas at San Antonio From icon-group-sender Wed Dec 1 10:01:23 1993 Received: by cheltenham.cs.arizona.edu; Wed, 1 Dec 1993 10:02:19 MST Date: Wed, 1 Dec 93 10:01:23 MST From: gmt (Gregg Townsend) Message-Id: <9312011701.AA00526@owl.cs.arizona.edu> To: icon-group Subject: set insertion during generation Content-Length: 25796 Status: R Errors-To: icon-group-errors@cs.arizona.edu [ Here are several related messages from the comp.lang.icon newsgroup, forwarded to the Icon-group mailing list as one long message. ] ------------------------------------------------------------------------ From: norman@flaubert.bellcore.com (Norman Ramsey) Organization: Bellcore Date: Tue, 23 Nov 1993 03:50:18 GMT What guarantees does Icon provide if I alter a structured value in the middle of generating elements of that value? s := set() ... every x := !s do if p(x) then delete(s, x) else insert(s, [x]) Is open(mumble, "bp") legitimate, and if so, what are its semantics? (I want to write, e.g., `nntpserver := open("telnet foo 119", "bp")' and have my Icon program talk to an NNTP server.) Norman -- Norman Ramsey norman@bellcore.com ------------------------------------------------------------------------ From: nevin@CS.Arizona.EDU (Nevin Liber) Date: 23 Nov 1993 05:59:38 -0700 Organization: University of Arizona CS Department, Tucson AZ In article , Norman Ramsey wrote: >What guarantees does Icon provide if I alter a structured value in the >middle of generating elements of that value? > s := set() > ... > every x := !s do if p(x) then delete(s, x) else insert(s, [x]) None, I believe. What kind if guarantees were you expecting? You are generating elements from a collection of unordered (important point here), unique elments. Any guarantees that I can think of would force order on that collection. In reality, if you use ! on the same set twice, you get the elements in the same order, because from an implementation point of view, it takes work to create a nonpredictable, random order for things. But implementations can change. If you want a guarantee like, say, all elements of the original set should be generated, you could use a construct like: every x := !copy(s) do ... >Is open(mumble, "bp") legitimate, and if so, what are its semantics? I believe that it is legitimate. Although its been a while since I looked the Icon source code, I believe that it just passes the flags down to C, so it would have the same semantics as opening a pipe under C. -- Nevin ":-)" Liber nevin@cs.arizona.edu (602) 293-2799 ------------------------------------------------------------------------ From: Darren New Organization: Bellcore Date: Tue, 23 Nov 1993 14:16:25 GMT > >What guarantees does Icon provide if I alter a structured value in the > >middle of generating elements of that value? > None, I believe. What kind if guarantees were you expecting? Perhaps the kind of guarantee that the Hermes language offers, which is that the effect of the iterator is as if the tabler/set/list/whatever being iterated over is copied before iteration starts (which is, I think, what the compiler does if there are any modifications to its contents within the scope of the loop). Nothing to do with the order of iteration at all. That is, I think the point is "if I insert an element into a set I'm iterating over, will it always/never/sometimes show up in the iteration?" > In reality, if you use ! on the same set twice, you get the elements in > the same order, because from an implementation point of view, it takes > work to create a nonpredictable, random order for things. But > implementations can change. Actually, there was talk of assuring different orders of iteration during different runs of a Hermes program, merely to prevent programs from being accidentally written that depend on the order of iteration. Now *that* is user-friendly. :-) ------------------------------------------------------------------------ From: swampler@noao.edu (Steve Wampler) Organization: National Optical Astronomy Observatories, Tucson AZ Date: Tue, 23 Nov 1993 15:24:30 GMT In article , Darren New writes: |> > >What guarantees does Icon provide if I alter a structured value in the |> > >middle of generating elements of that value? |> > None, I believe. What kind if guarantees were you expecting? |> Perhaps the kind of guarantee that the Hermes language offers, which is |> that the effect of the iterator is as if the tabler/set/list/whatever |> being iterated over is copied before iteration starts (which is, I |> think, what the compiler does if there are any modifications to its |> contents within the scope of the loop). Nothing to do with the order of |> iteration at all. Careful. Icon doesn't iterate over objects, but across result sequences. (I.e. every just drives goal-directed evaluation(GDE) through all results of an expression.) I don't think you'd want to use a language that copied all data objects in expressions that are involved in GDE! consider: every a <- !s1 || !s2 || !s3 do {...} how many copies of s3 would have to be produced during evaluation of this? (And I would imagine the evaluation mechanism would have to be pretty complicated to manage the above...) Finally, what about the cases where you're not driving GDE with an every, but there is still GDE taking place? e.g.: match(!s1 || !s2, !s3) again, I think there'd be a pretty hefty performance hit to provide any sort of 'guarantee'. (Not to mention the complexity if !s3 is replaced with f(s3).) ------------------------------------------------------------------------ From: dnew@thumper.bellcore.com (Darren New) Date: 23 Nov 93 17:02:00 GMT Organization: Bellcore > Careful. Icon doesn't iterate over objects, but across result sequences. This is a good point. But Hermes iterates over "tables" (i.e., relational database-like tables) so that doesn't come up here. It also only copies when such copying is needed to ensure the semantics. > (I.e. every just drives goal-directed evaluation(GDE) through all results of an expression.) This kind of begs the question, tho. What's the behavior of ! in this case, then? If "every" is just the GDE control structure, then "!" should have some defined semantics (or explicitly undefined semantics, yuck) as to what it does if the argument is changed while suspended. I wasn't arguing for copying, BTW. That was just an example of semantics. Another example might be to give a function body (including suspends, returns, and fails) that is the equivalent of each built in operator (like !). Something like the listing of "tab()" on page 178 of the second ed of The Icon Programming Language. > again, I think there'd be a pretty hefty performance hit to provide > any sort of 'guarantee'. (Not to mention the complexity if !s3 is > replaced with f(s3).) Well, I would rather have a performance hit than have a program that works fine with one version of Icon and coredumps with another. That sounds too much like C to me. ;-) If I need to copy it in some circumstances (e.g., I'm adding a new element to a set for every element already in the set) then I need to know whether I'm going to see all the new elements or not. If I *might* see the new elements, that's a guarantee too, in that I'm guaranteed to have to copy the set myself before starting. But leaving it undefined tends to cause people to "try and see," which works poorly when you upgrade the interpreter, or use the compiler instead, or port it from UNIX to MS-DOS, or whatever. -- Darren ------------------------------------------------------------------------ From: espie@basilic.ens.fr (Marc Espie) Organization: LIENS, ENS, 45 rue d'Ulm, Paris (France) Date: Wed, 24 Nov 93 09:45:13 GMT In article dnew@thumper.bellcore.com (Darren New) writes: [...] > >I wasn't arguing for copying, BTW. That was just an example of >semantics. Another example might be to give a function body (including >suspends, returns, and fails) that is the equivalent of each built in >operator (like !). Something like the listing of "tab()" on page 178 of >the second ed of The Icon Programming Language. > >> again, I think there'd be a pretty hefty performance hit to provide >> any sort of 'guarantee'. (Not to mention the complexity if !s3 is >> replaced with f(s3).) > >Well, I would rather have a performance hit than have a program that >works fine with one version of Icon and coredumps with another. That >sounds too much like C to me. ;-) >If I need to copy it in some circumstances (e.g., I'm adding a new >element to a set for every element already in the set) then I need to >know whether I'm going to see all the new elements or not. If I *might* >see the new elements, that's a guarantee too, in that I'm guaranteed to >have to copy the set myself before starting. But leaving it undefined >tends to cause people to "try and see," which works poorly when you >upgrade the interpreter, or use the compiler instead, or port it from >UNIX to MS-DOS, or whatever. -- Darren > Ok, how about that for a semantics: if you try and add an element to the set while you're scanning it and resume the scan, you get a runtime error. Sounds pretty reasonable to me. - cheap to implement. - well-defined semantics. What are you doing adding elements to a set while you're scanning it anyway ? That's unelegant, relies on side-effects, and not a good idea anyway. One very good thing about Icon is: keep it simple. Understandable semantics, orthogonal language, everything set up carefully... Anyway, considering the overall structure of the language, except IF you're a very, very naughty programmer, such a hack as adding an element in the middle of a scan would be fixed in a jiffy. -- [nosave] Marc Espie (Marc.Espie@ens.fr) ``I'm gonna dance the dream And make the dream come true'' ------------------------------------------------------------------------ From: dnew@thumper.bellcore.com (Darren New) Date: 24 Nov 93 14:16:36 GMT Organization: Bellcore > Ok, how about that for a semantics: if you try and add an element to the > set while you're scanning it and resume the scan, you get a runtime error. Sounds reasonable to me. Better than having it work on some platforms and fail on others. > What are you doing adding elements to a set while you're scanning it anyway ? > That's unelegant, relies on side-effects, and not a good idea anyway. Oh baloney. Take a set of employee's names. Iterate thru it and add to it the set of spouses of those names. You now have the set of people covered by the insurance. There's lots of reasons why you'd want to do something like that. I don't see why it's more elegant to use two sets (if the semantics said you needn't, which they don't in Icon), and I don't see why relying on side-effects is a problem in a language like Icon. > Understandable semantics, Debatable, as this discussion shows... > orthogonal language, everything set up carefully... Yes. Icon *is* very nice. No question there. Most of my code works the first time it runs to completion without a run-time error. And most of the run-time errors are pretty trivial to fix, on the order of syntax errors. > such a hack as adding an element in the middle of a scan would be fixed > in a jiffy. Sure, if the semantics were "don't do this." It's a shame there aren't more languages with formal semantics of some form. -- 445 South St/MRE 2E-279/Morristown NJ 07960 USA/(201)829-4833 Delivery of Electronic Multimedia over Networks (DEMON) Also, formal description techniques, programming languages. ``Your fault: Core dumped.'' EFF#846 ``Sometimes, you just have to bite the silver bullet.'' ------------------------------------------------------------------------ From: nevin@CS.Arizona.EDU (Nevin Liber) Date: 24 Nov 1993 12:22:39 -0700 Organization: University of Arizona CS Department, Tucson AZ In article , Darren New wrote: >Perhaps the kind of guarantee that the Hermes language offers, which is >that the effect of the iterator is as if the tabler/set/list/whatever >being iterated over is copied before iteration starts (which is, I >think, what the compiler does if there are any modifications to its >contents within the scope of the loop). If you need that guarantee, it is fairly easy to implement (generate over copy(s) instead of s). Personally, just about all my code doesn't modify a data structure if it is being generated upon via !. >That is, I think the point is "if I insert an element into a set I'm >iterating over, will it always/never/sometimes show up in the >iteration?" Sometimes (it "generates" them in the order it is stored in the internal hash table, I believe.) >Actually, there was talk of assuring different orders of iteration >during different runs of a Hermes program, merely to prevent programs >from being accidentally written that depend on the order of iteration. >Now *that* is user-friendly. :-) For development, I totally agree. However, once I am done writing/debugging/modifying the code, I don't want to pay this performance penalty. I'd rather have the computer spending its cycles doing useful work for me. -- Nevin ":-)" Liber nevin@cs.arizona.edu (602) 293-2799 ------------------------------------------------------------------------ From: nevin@CS.Arizona.EDU (Nevin Liber) Date: 24 Nov 1993 12:40:13 -0700 Organization: University of Arizona CS Department, Tucson AZ In article , Darren New wrote: >case, then? If "every" is just the GDE control structure, then "!" >should have some defined semantics (or explicitly undefined semantics, >yuck) as to what it does if the argument is changed while suspended. I disagree with the "yuck" part of your statement. Typically, if you are pressed to define the semantics for something uncommon (like modifying a structure you are iterating over), you pretty much lock yourself into only one possible implementation. Also, from a code maintenance point of view, this makes the language harder to master because there are more of these special cases to memorize. Here is an example: in the map(sString, sSource, sDestination) function, is disambiguation of duplicate characters in sSource done left-to-right or right-to-left? Wouldn't it have been simpler to just say this results in undefined behavior and should be avoided, than to pin it down based on the implementation? As a matter of fact, if there was a "debug" version of Icon, it could actually check for these violations, while in the "production" version, you don't get the performance hit. >Well, I would rather have a performance hit than have a program that >works fine with one version of Icon and coredumps with another. While I'm developing something, I totally agree with you. But I don't want my production system to suffer because of these checks. >If I need to copy it in some circumstances (e.g., I'm adding a new >element to a set for every element already in the set) then I need to >know whether I'm going to see all the new elements or not. I don't see how you can ask for this, without wanting an implicit order on the set (eg: by time) or copy first semantics (which is still ordering by time; it just says that you don't want any elements produced after the set was instanciated by !). >If I *might* >see the new elements, that's a guarantee too, in that I'm guaranteed to >have to copy the set myself before starting. That's all I would count on. It's the "safest" assumption. Anything else would make me look it up every time I saw it. >But leaving it undefined >tends to cause people to "try and see," which works poorly when you >upgrade the interpreter, or use the compiler instead, or port it from >UNIX to MS-DOS, or whatever. Agreed. Actually, a good reference on this kind of stuff is "Writing Solid Code", by Steve MaGuire, published by Microsoft Press. -- Nevin ":-)" Liber nevin@cs.arizona.edu (602) 293-2799 ------------------------------------------------------------------------ From: nevin@CS.Arizona.EDU (Nevin Liber) Date: 24 Nov 1993 12:49:04 -0700 Organization: University of Arizona CS Department, Tucson AZ In article <1993Nov24.094513.20348@ens.fr>, Marc Espie wrote: >Ok, how about that for a semantics: if you try and add an element to the >set while you're scanning it and resume the scan, you get a runtime error. >Sounds pretty reasonable to me. >- cheap to implement. >- well-defined semantics. I'm not convinced that it is all that cheap to implement (then again, I'm really sleepy right now, so take what I say with a grain of salt :-)). Consider the following code fragment: every x := !S do { ... insert(S, foo) ... every y := !S do { ... } } How do you keep track of whether you are resuming the first one or the second one (or the nth one, if being called recursively)? I think that this will get messy. I also believe that run-time errors are a last-ditch bailing mechanism, when you can't think of anything reasonable to do. Then again, maybe that does apply here. >What are you doing adding elements to a set while you're scanning it anyway ? >That's unelegant, relies on side-effects, and not a good idea anyway. I agree with you 100% here, and never do it myself. -- Nevin ":-)" Liber nevin@cs.arizona.edu (602) 293-2799 ------------------------------------------------------------------------ From: nevin@CS.Arizona.EDU (Nevin Liber) Date: 24 Nov 1993 12:55:44 -0700 Organization: University of Arizona CS Department, Tucson AZ In article , Darren New wrote: >> What are you doing adding elements to a set while you're scanning it anyway ? >> That's unelegant, relies on side-effects, and not a good idea anyway. >Oh baloney. Take a set of employee's names. Iterate thru it and add to >it the set of spouses of those names. You now have the set of people >covered by the insurance. There's lots of reasons why you'd want to do >something like that. I don't see why it's more elegant to use two sets >(if the semantics said you needn't, which they don't in Icon), and I >don't see why relying on side-effects is a problem in a language like >Icon. Well, there is nothing wrong with doing that from a language point of view. However, I would claim that you are breaking the abstraction of what that set stands for. First it is a set of employee names; now it is a set of people covered by insurance. If I want to convert one of these to another, I use two different variables, because I am naming two different types of objects. Unless you are really, really pressed for space efficiency, I believe that it is much clearer to use two different sets for this. -- Nevin ":-)" Liber nevin@cs.arizona.edu (602) 293-2799 ------------------------------------------------------------------------ From: norman@flaubert.bellcore.com (Norman Ramsey) Organization: Bellcore Date: Wed, 24 Nov 1993 21:06:44 GMT >>What guarantees does Icon provide if I alter a structured value in the >>middle of generating elements of that value? >> s := set() >> ... >> every x := !s do if p(x) then delete(s, x) else insert(s, [x]) > >None, I believe. What kind if guarantees were you expecting? Here are some possible guarantees: - every element that was in s before `every' started executing will be generated - inserted elements might be generated, might not - inserted elements won't be generated - inserted elements will be generated Here is what I fear: - the behavior of the construct is undefined Norman ------------------------------------------------------------------------ From: norman@flaubert.bellcore.com (Norman Ramsey) Organization: Bellcore Date: Wed, 24 Nov 1993 21:10:31 GMT >What are you doing adding elements to a set while you're scanning it anyway ? >That's unelegant, relies on side-effects, and not a good idea anyway. Nonsense. every x := !s & type(x) == "field" & insert(s, !extensions[x]) makes sure s is closed under the ``extensions'' relation. (In this case I needn't worry about generating elements of extensions[x] because they never have type "field".) ------------------------------------------------------------------------ From: Darren New Organization: Bellcore Date: Wed, 24 Nov 1993 22:42:00 GMT > First it is a set of employee names; now it is a set of people covered by insurance. Nope. I just want the people covered by insurance. However, all I have access to is two different tables: employees, and their spouses. There has to be an intermediate expression where only some of the people are in the set. If nothing else, you can't generate a set of employees because you have to insert them in the set one at a time, see. So at *some* point the set will be "the set of employees I've gotten around to inserting so far." Maybe if we were using SQL I could do it with one loop. But that isn't always possible in Icon. ------------------------------------------------------------------------ From: gmt@CS.Arizona.EDU (Gregg Townsend) Date: 24 Nov 1993 17:37:51 -0700 Organization: University of Arizona CS Department, Tucson AZ Fear not. It is safe to insert and delete items of a set while the set is being generated. Items that are neither inserted nor deleted are generated exactly once. Norman Ramsey and Darren New each gave an example of why this is useful. An inserted item may or may not be generated once, depending on enough different factors that you might as well consider it random. Gregg Townsend / Icon Project / Computer Science Dept / Univ of Arizona +1 602 621 4325 gmt@cs.arizona.edu 110 57 16 W / 32 13 45 N / +758m ------------------------------------------------------------------------ From: nevin@CS.Arizona.EDU (Nevin Liber) Date: 28 Nov 1993 08:14:38 -0700 Organization: University of Arizona CS Department, Tucson AZ In article , Norman Ramsey wrote: > Here are some possible guarantees: > ... > - inserted elements might be generated, might not >Here is what I fear: > - the behavior of the construct is undefined I'm not sure why you accept the first statement as a useful guarantee, and fear the second one. From a practical point of view, I can find no difference between statement one and statement two, as far as inserted elements are concerned. Is there any possible situation where you can do something if statement one is guaranteed, vs it being undefined? -- Nevin ":-)" Liber nevin@cs.arizona.edu (602) 293-2799 ------------------------------------------------------------------------ From: norman@flaubert.bellcore.com (Norman Ramsey) Date: 29 Nov 93 02:02:11 GMT Organization: Bellcore, Morristown NJ In article <2daf8u$jnl@caslon.cs.arizona.edu>, Nevin Liber wrote: >> - inserted elements might be generated, might not >> - the behavior of the construct is undefined > >I'm not sure why you accept the first statement as a useful guarantee, >and fear the second one. From a practical point of view, I can find no >difference between statement one and statement two In language definition, `behavior undefined' means `anything can happen', including a runtime error that brings down the program. There are lots of examples in the C standard. Norman ------------------------------------------------------------------------ From: nevin@CS.Arizona.EDU (Nevin Liber) Date: 29 Nov 1993 07:45:59 -0700 Organization: University of Arizona CS Department, Tucson AZ In article , Norman Ramsey wrote: >In article <2daf8u$jnl@caslon.cs.arizona.edu>, >Nevin Liber wrote: >>> - inserted elements might be generated, might not >>> - the behavior of the construct is undefined >In language definition, `behavior undefined' means `anything can >happen', including a runtime error that brings down the program. >There are lots of examples in the C standard. But I don't find the statement "Anything can happen except a runtime error, theomonuclear war, etc." any more useful than saying "Anything can happen" (undefined). If you believe otherwise, please post a code fragment where you can do something useful with "inserted elements might or might not be generated" as the semantics vs "undefined" as the semantics. Sentences with the phrases "might", "might not", "may", "may not", "might or might not", "may or may not" are pretty much unnecessary in a technical definition. They are useful only for pointing something out the reader might have overlooked. You can exchange any one of the above phrases with any other one of the above phrases or take the whole sentence out without changing the meaning of the definition. -- Nevin ":-)" Liber nevin@cs.arizona.edu (602) 293-2799 ------------------------------------------------------------------------ From: norman@flaubert.bellcore.com (Norman Ramsey) Organization: Bellcore, Morristown NJ Date: Mon, 29 Nov 1993 23:04:11 GMT >But I don't find the statement "Anything can happen except a runtime >error, theomonuclear war, etc." any more useful than saying "Anything >can happen" (undefined). > >If you believe otherwise, please post a code fragment where you can do >something useful with "inserted elements might or might not be >generated" as the semantics vs "undefined" as the semantics. Under the invariant that no value in t has type integer, every type(x := !s) == "integer" do insert(s, t[x]) is safe and well defined in the maybe, maybe not semantics. In the undefined semantics it's unsafe and I'm forced to write ss := set() every type(x := !s) == "integer" do insert(ss, t[x]) every insert(s, !ss) From icon-group-sender Tue Dec 7 11:15:50 1993 Received: by cheltenham.cs.arizona.edu; Wed, 8 Dec 1993 07:49:56 MST Via: uk.ac.edinburgh.festival; Tue, 7 Dec 1993 11:15:58 +0000 Date: 07 Dec 93 11:15:50 GMT From: R J Hare Subject: Sharp PC3100 To: icon-group@cs.arizona.edu Organisation: Edinburgh University Computing Service Message-Id: <9312071115.aa02769@uk.ac.ed.festival> Status: R Errors-To: icon-group-errors@cs.arizona.edu I have just tried running Icon on a Sharp PC3100 'Pocket PC'. I was pleasantly surprised at how quickly the executor seemed to run the interpreted code (although it was a *very* simple program), and am now thinking of purchasing one of these machines for program development when on the bus/train/etc. Does anyone else have any experience of using these (or similar) machines as an Icon platform? Any advice, information, warnings, etc. gratefully received. Thanks. Roger Hare. From icon-group-sender Wed Dec 8 07:49:45 1993 Received: by cheltenham.cs.arizona.edu; Wed, 8 Dec 1993 10:06:18 MST Date: Wed, 8 Dec 1993 07:49:45 MST From: "Cliff Hathaway" Message-Id: <199312081449.AA20560@cheltenham.cs.arizona.edu> To: icon-group Subject: Idol mailinglist announcement Status: R Errors-To: icon-group-errors@cs.arizona.edu This may be of interest to others on the icon-group mailinglist and readers of comp.lang.icon. Idol is an object-oriented extension of Icon, written by Clint Jeffery, and available as part of the Icon Program Library. - cliff > From aquin!luvthang!talmage@men2a.ori-cal.com Wed Dec 8 03:42:22 1993 > Subject: Idol Group available again > > The Idol Group, an unmoderated mailing list for Idol programmers, is > available again. About a year ago, luvthang, the machine that services > the Idol Group, lost its mail feed and so the mailing list disappeared. > Luvthang has a new feed, so the mailing list can start up again. > > If you wish to join the list, please send a short request to > idol-group-request@luvthang. > > If you wish to post something to the list, please send it to > idol-group@luvthang. > > ----------------------------------------------------------------------------- > David W. Talmage (uunet!aquin!luvthang!talmage) > "Once more. This is deixis. This is your brain on deixis. Any questions?" > From icon-group-sender Thu Dec 9 18:37:18 1993 Received: by cheltenham.cs.arizona.edu; Fri, 10 Dec 1993 09:27:02 MST Date: Thu, 9 Dec 93 18:37:18 CST From: johnp@utafll.uta.edu (John Paolillo) Message-Id: <9312100237.AA21260@utafll.uta.edu> To: icon-group@cs.arizona.edu Subject: An immodest proposal Status: R Errors-To: icon-group-errors@cs.arizona.edu Hi, folks, I've been doing some thinking about what it would take to get a really great implementation of my favorite language (Icon, of course) on my favorite platform (mac). While the current implementations are useful for most tasks, they have certain limitations which make it hard for me to utilize much of the potential that is there. MPW icon is not feasible for me (who has MPW?), and the standalone version has a clunky interface. ProIcon has a nice interface, but it lacks (as does the standalone) features that are necessary for some things (e.g. if one wants to do idol, one must have a "system" command that works). The idea that occurred to me was that it might be possible for someone clever to implement icon as an OSA (Open Scripting Architecture) extension for the mac. Three such languages (AppleScript, UserTalk, and TCL) now exist. The concept behind them is something like batch processing -- they manage the functions of the mac user interface through inter- applications communications. the "scripts" written in these languages function like applications in the mac environment (you double-click them, drag things onto them, etc.). So part of my idea is that if Icon for mac were designed in the same way ("OSAIcon"), one could run icon programs in a manner analogous to direct execution under Unix or Dos environments (something I would really like). There are other potential benefits, too. The programmer implementing Icon on the mac would not have to be concerned as much with the peculiarities of the mac user interface. There are already OSA "scripting extensions" which handle some of that, and other applications (that support inter-application communication) would provide the rest. One would be able to use icon to drive or process data in other applications (e.g. databases, word processors graphics programs, etc.), something I would really like to do. And maybe I could convince a linguistics department just how useful Icon really is. Can someone comment on whether what I am suggesting is reasonable? Is there anyone out there with the time and the ability to do this? Sorry to have gone on so long. John C. Paolillo Linguistics Program University of Texas at Arlington From icon-group-sender Fri Dec 3 10:23:49 1993 Received: by cheltenham.cs.arizona.edu; Tue, 14 Dec 1993 15:41:13 MST Date: 3 Dec 93 10:23:49 GMT From: rpereda@arizona.edu (Ray Erasmo Pereda) Organization: U of Arizona, CS Dept, Tucson Subject: Re: two language questions Message-Id: <2dn43l$9ms@optima.cs.arizona.edu> References: <2ct1fq$aqn@caslon.CS.Arizona.EDU>, , <2d0uov$ub@owl.CS.Arizona.EDU> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: RO Errors-To: icon-group-errors@cs.arizona.edu In article <2d0uov$ub@owl.CS.Arizona.EDU>, gmt@CS.Arizona.EDU (Gregg Townsend) writes: |> Fear not. It is safe to insert and delete items of a set while the set is |> being generated. Items that are neither inserted nor deleted are generated |> exactly once. Norman Ramsey and Darren New each gave an example of why |> this is useful. |> |> An inserted item may or may not be generated once, depending on enough |> different factors that you might as well consider it random. |> Does the same hold for lists and tables? From icon-group-sender Fri Dec 3 21:40:10 1993 Received: by cheltenham.cs.arizona.edu; Tue, 14 Dec 1993 16:14:59 MST Article: 2306 of comp.lang.icon Path: CS.Arizona.EDU!not-for-mail From: gmt@cs.arizona.edu (Gregg Townsend) Newsgroups: comp.lang.icon Subject: Re: two language questions Date: 3 Dec 1993 21:40:10 -0700 Organization: University of Arizona CS Department, Tucson AZ Lines: 10 Message-Id: <2dp4ba$k4@owl.CS.Arizona.EDU> References: <2d0uov$ub@owl.CS.Arizona.EDU> <2dn43l$9ms@optima.cs.arizona.edu> Nntp-Posting-Host: owl.cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Apparently-To: icon-group-addresses I wrote: > Fear not. It is safe to insert and delete items of a set while the set is > being generated. Items that are neither inserted nor deleted are generated > exactly once. Ray Erasmo Pereda asks: > Does the same hold for lists and tables? Yes. Tables and sets share the same code. Lists should also be safe. From icon-group-sender Sat Dec 4 22:31:04 1993 Received: by cheltenham.cs.arizona.edu; Tue, 14 Dec 1993 17:09:02 MST Article: 2309 of comp.lang.icon Path: CS.Arizona.EDU!not-for-mail From: nevin@cs.arizona.edu (Nevin Liber) Newsgroups: comp.lang.icon Subject: Re: two language questions Date: 4 Dec 1993 22:31:04 -0700 Organization: University of Arizona CS Department, Tucson AZ Lines: 41 Message-Id: <2drrmo$iu3@caslon.CS.Arizona.EDU> References: <2dd1v7$p98@caslon.cs.arizona.edu> Nntp-Posting-Host: caslon.cs.arizona.edu Status: RO Errors-To: icon-group-errors@cs.arizona.edu Apparently-To: icon-group-addresses In article , Norman Ramsey wrote: > I, Nevin Liber, nevin@cs.arizona.edu, wrote: NL> If you believe otherwise, please post a code fragment where you can do NL> something useful with "inserted elements might or might not be NL> generated" as the semantics vs "undefined" as the semantics. NR> Under the invariant that no value in t has type integer, NR> NR> every type(x := !s) == "integer" do insert(s, t[x]) NR> NR> is safe and well defined in the maybe, maybe not semantics. You're right. I concede. If you have a way to ignore (at least) all elements that were not in the original set (ie, degenerate the "maybe / maybe" not semantics to the stronger "definitely not" semantics), this is a perfectly well defined concept. Very clever. NR> In the NR> undefined semantics it's unsafe and I'm forced to write NR> ss := set() NR> every type(x := !s) == "integer" do insert(ss, t[x]) NR> every insert(s, !ss) Actually, I would change the last line to s ++:= ss, and I would claim that these three lines are more readable/understandable/maintainable than the one-liner (although this is an orthogonal issue to the original discussion), although certainly not as space-efficent. Personally, I like code that doesn't rely on hidden dependencies (such as the fact that t has no integer values in the above example). But I digress. Now that I think about it, if I needed time-efficiency, I might implement the above three lines as: l := list() every "integer" == type(x := !s) do put(l, t[x]) s ++:= set(l) -- Nevin ":-)" Liber nevin@cs.arizona.edu (602) 293-2799 From icon-group-sender Mon Dec 6 17:34:35 1993 Received: by cheltenham.cs.arizona.edu; Tue, 14 Dec 1993 17:24:27 MST Date: 6 Dec 93 17:34:35 GMT From: walter!flaubert!norman@uunet.uu.net (Norman Ramsey) Organization: Bellcore, Morristown NJ Subject: Re: two language questions Message-Id: References: <2dd1v7$p98@caslon.cs.arizona.edu>, , <2drrmo$iu3@caslon.cs.arizona.edu> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: RO Errors-To: icon-group-errors@cs.arizona.edu >NR> every insert(s, !ss) > >Actually, I would change the last line to s ++:= ss, Different semantics. I get bitten by this almost every time I write code that's supposed to have a side effect on a set, such as an analog of insert(). It's a pity since ++:= is much clearer. From icon-group-sender Tue Dec 14 17:42:10 1993 Received: by cheltenham.cs.arizona.edu; Tue, 14 Dec 1993 17:39:55 MST Date: Tue, 14 Dec 93 17:42:10 CST From: jeffery@ringer.cs.utsa.edu (Clinton L. Jeffery) Message-Id: <9312142342.AA18337@ringer.cs.utsa.edu.sunset> To: rpereda@arizona.edu Cc: icon-group@cs.arizona.edu In-Reply-To: (Ray Erasmo Pereda's message of 3 Dec 93 10:23:49 GMT <2dn43l$9ms@optima.cs.arizona.edu> Subject: two language questions Content-Length: 681 Status: R Errors-To: icon-group-errors@cs.arizona.edu gmt@CS.Arizona.EDU (Gregg Townsend) writes: |> It is safe to insert and delete items of a set while the set |> is being generated. Items that are neither inserted nor deleted are |> generated exactly once. To which Ray Pereda asks: Does the same hold for lists and tables? No and yes. Tables share the implementation of sets and exhibit similar behavior. Watch what happens when you delete already-generated elements from a list during the middle of generation: procedure main() L := [1, 2, 3, 4] every e := !L do { pop(L); pop(L); write(e) } end writes: 1 4 My, how interesting! It gets wilder when you delete lots of elements from larger lists. From icon-group-sender Mon Dec 13 08:31:53 1993 Received: by cheltenham.cs.arizona.edu; Tue, 14 Dec 1993 18:01:36 MST Date: 13 Dec 93 08:31:53 GMT From: csus.edu!netcom.com!rfg@decwrl.dec.com (Ronald F. Guilmette) Organization: NETCOM On-line Communication Services (408 241-9760 guest) Subject: Need help with (simple?) programming problem. Message-Id: Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: RO Errors-To: icon-group-errors@cs.arizona.edu My thanks to to the several people who replied to my earlier request for general information about the nature of ICON. I have obtained Griswold's 2nd Edition book, and (believe it or not) I already plowed most of the way through it (although I confess that I only skimmed most of the parts relating to string scanning). The book is well written, which I appreciate greatly. Naturally, as with every language I've ever studied, there are a few minor things I might change (adding enum types for example) but I'll save those comments for another message (to be posted someday after I feel like I've reached at least the ICON brown-belt level). Anyway, today I need/want to solve a real problem, and I'm hoping one or more of you ICON gurus will lend me a hand. In a nutshell, here's what I want to do... Assume that I have three strings, i.e. "red ", "green ", and "blue ". Now I want to create a generator which will successively yield each unique string which contains no more than one instance of each of the original strings. Here are the string values which should be yielded by the various invocations/resumptions of the generator: "" "red " "green " "blue " "red green " "red blue " "green red " "green blue " "blue red " "blue green " "red green blue " "red blue green " "green red blue " "green blue red " "blue red green " "blue green red " After being invoked/resumed 16 times (and yielding each of the above strings once) the generator should fail. Note that the actual *order* in which the above strings are yielded is totally unimportant. Any order will do as long as I get these 16 strings (eventually). Also note that the ORDER in which the original strings appear in the genera- ted strings *is* significant. This is just an example of the kind of thing I want to learn how to do. Basically, I'm hoping that someone will be able to show me some GENERAL techinque for creating a generator along these lines. (In practice, for my *real* problem, the number of original strings will in fact be larger than three... but it *will* be a fixed number (probably less that 12). Is there a simple solution and/or well-known idiom for this general class of problems in ICON? If so, some example code would be most enlightening. P.S. It probably makes no difference, but in the case of my *real* problem, one or more of the "original strings" may not actually be strings at all. They may instead be generators which produce various strings. But the rules of the game will remain essentially the same, i.e. the strings yielded by my new generator must never contain any more than one instance of any one of the "inputs" (where an "input" could be either a literal string, or any one of the strings yielded by a given "input generator". For example: procedure greenish_input_generator () suspend "green " | "light-green " end I never want to see any more than one greenish color in the strings yielded by my new generator. -- -- Ronald F. Guilmette, Sunnyvale, California ------------------------------- ------ domain address: rfg@netcom.com --------------------------------------- ------ uucp address: ...!uunet!netcom.com!rfg ------------------------------- From icon-group-sender Mon Dec 13 15:34:08 1993 Received: by cheltenham.cs.arizona.edu; Wed, 15 Dec 1993 07:40:27 MST Date: 13 Dec 93 15:34:08 GMT From: dog.ee.lbl.gov!overload.lbl.gov!agate!howland.reston.ans.net!vixen.cso.uiuc.edu!uchinews!quads!goer@ucbvax.Berkeley.EDU (Richard L. Goerwitz) Organization: University of Chicago Subject: Re: Need help with (simple?) programming problem. Message-Id: <1993Dec13.153408.9174@midway.uchicago.edu> References: Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Ronald F. Guilmette writes: > >I have obtained Griswold's 2nd Edition book, and (believe it or not) I >already plowed most of the way through it (although I confess that I only >skimmed most of the parts relating to string scanning). The book is well >written, which I appreciate greatly. String scanning is, along with generators and backtracking, one of the salient features of Icon. No brown belt until you pass this milestone :-). -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Mon Dec 6 22:04:37 1993 Received: by cheltenham.cs.arizona.edu; Wed, 15 Dec 1993 13:12:34 MST Date: 6 Dec 93 22:04:37 GMT From: netcomsv!netcom.com!rfg@decwrl.dec.com (Ronald F. Guilmette) Organization: NETCOM On-line Communication Services (408 241-9760 guest) Subject: Capsule summary of the ICON language wanted Message-Id: Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Has anyone got anything approximating an "executive summary" kind of description of the ICON programming language? If so, could you please E-mail it to me? Basically, my situation is this... I know *nothing* about ICON other that the fact that it was inspiried/implemented by the same fellow who developed SNOBOL. On that basis alone, I assume it's good for programming tasks involving the manipulations of strings. As it happens, I need to do some rather fancy kinds of text manipulation, so I'm just wondering if ICON will be the right tool for the job. (It is at least plausible that ICON would actually be overkill for the kinds of things I need to do, and I may end up just using m4 or something like that.) So if anyone could provide me with a capsule summary of ICON, I'd really appreciate it. In particular, I'd like to know: o In a nutshell, what is ICON? o What kinds of programming tasks is ICON especially well suited for? o What kinds of programming tasks would you refuse to do in any language OTHER THAN ICON? Please send any replies to me via E-mail, as I am NOT a regular reader of this newsgroup (yet). Thanks. -- -- Ronald F. Guilmette, Sunnyvale, California ------------------------------- ------ domain address: rfg@netcom.com --------------------------------------- ------ uucp address: ...!uunet!netcom.com!rfg ------------------------------- From icon-group-sender Wed Dec 15 15:46:59 1993 Received: by cheltenham.cs.arizona.edu; Wed, 15 Dec 1993 18:26:11 MST Message-Id: <9312152344.AA26970@enlil.premenos.sf.ca.us> From: Ken Walker Subject: Re: Need help with (simple?) programming problem. To: icon-group@cs.arizona.edu Date: Wed, 15 Dec 93 15:46:59 PST Mailer: Elm [revision: 66.25] Status: R Errors-To: icon-group-errors@cs.arizona.edu > From Ronal F. Guilmette: > > Assume that I have three strings, i.e. "red ", "green ", and "blue ". Now > I want to create a generator which will successively yield each unique > string which contains no more than one instance of each of the original > strings. Here are the string values which should be yielded by the various > invocations/resumptions of the generator: > > "" > "red " > "green " > "blue " > "red green " > "red blue " > "green red " > "green blue " > "blue red " > "blue green " > "red green blue " > "red blue green " > "green red blue " > "green blue red " > "blue red green " > "blue green red " > > After being invoked/resumed 16 times (and yielding each of the above strings > once) the generator should fail. Note that the actual *order* in which the > above strings are yielded is totally unimportant. Any order will do as long > as I get these 16 strings (eventually). > > Also note that the ORDER in which the original strings appear in the genera- > ted strings *is* significant. I found the hard part was formulating the problem in "constructive" terms. The problem, as I understand it, is to generate all the permutaions of all the subsets of a list of words. Once it is formulated that way, it is simple to solve using two recursive generators (permutaions has certainly been done using this technique before, and I suspect subsets has also). Here is a solution using list invocation: procedure main() p("red", "blue", "green") end procedure p(words[]) every write(permute ! (subsets ! words)) end procedure subsets(words[]) local i, w, tail suspend [] every i := 1 to *words do { w := words[i : i + 1] tail := words[i + 1 : 0] suspend w ||| (subsets ! tail) } end procedure permute(words[]) local i, head, w, tail if *words = 0 then return "" every i := 1 to *words do { head := words[1 : i] w := words[i] tail := words[i + 1 : 0] suspend w || " " || (permute ! (head ||| tail)) } end Ken Walker, kwalker@premenos.sf.ca.us From icon-group-sender Wed Dec 15 20:12:49 1993 Received: by cheltenham.cs.arizona.edu; Wed, 15 Dec 1993 18:26:48 MST Date: 15 Dec 93 20:12:49 GMT From: agate!howland.reston.ans.net!news.moneng.mei.com!uwm.edu!fnnews.fnal.gov!fnalv.fnal.gov!mglass@ucbvax.Berkeley.EDU Organization: Fermi National Accelerator Lab Subject: Powersets and every x:=!S insert(S... Message-Id: <1993Dec15.141249.1@fnalo.fnal.gov> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu May I jump in and combine two recent threads? Specifically, the recent question about how to compute a powerset intersects with the long discussion of "every x := !S do insert(S, ...)." One cool way to compute a powerset, given a set S, is: ps := set([set()]) every insert(ps, set([!S]) ++ !copy(ps)) This should be, I believe, a fairly convincing example of why even a rigorous programmer might occasionally write a statement of the form: "every x := !ps do insert(ps, ...)" It was suggested that using copy() will clean up the problem with such constructions, as it did above. If icon sets behaved like real sets, the following might work: * every insert(ps, set([!S]) ++ !ps) However one can hardly recommend such a practice! Suppose you were computing for example, the products of all the subsets, instead of the subsets themselves. Without invoking copy(), the following might not work: products := set([1]) every insert(products, !S * !copy(products)) An amusing side-note is the illusion that the "++" set union operator is not commutative! In my example !copy(ps) ++ set([!S]) is not the same as set([!S]) ++ !copy(ps) It is this apparent non-commutative behavior--really order of generation and evaluation--which bugged my original construction, which was to compute the powerset by successively _deleting_ elements: * ps := set(S) * every insert(ps, !copy(ps) -- set([!S])) Enough! -- Michael Glass | Practice random acts of mglass@fnalv.fnal.gov | humor and senseless mirth. From icon-group-sender Wed Dec 15 20:16:46 1993 Received: by cheltenham.cs.arizona.edu; Wed, 15 Dec 1993 18:27:05 MST Date: 15 Dec 93 20:16:46 GMT From: agate!howland.reston.ans.net!news.moneng.mei.com!uwm.edu!fnnews.fnal.gov!fnalv.fnal.gov!mglass@ucbvax.Berkeley.EDU Organization: Fermi National Accelerator Lab Subject: Problem for icon mavens Message-Id: <1993Dec15.141646.1@fnalo.fnal.gov> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu A question for icon mavens. If you have a list of numbers "L" and a limit "lim", the the following will produce all numbers from L which are less than the limit: suspend lim > !L If L happens to be sorted, and quite long, you might want to improve the process so it does not search the entire list. An easy way is: every x := !L do { if x < lim then suspend x else break } However in my application I have found that each iteration is so slow, and "lim" is often large enough, that the easy way is not much improved (on average) over the simple "suspend lim > !L." Where "binary_search(L, lim)" does the obvious, I have actually obtained better results with: suspend !L[1+:binary_search(L, lim)] So, icon mavens: What is the clever generation expression which mimics "suspend lim > !L" without actually scanning all of L? -- Michael Glass | Recently not spotted on a bumper sticker: mglass@fnalv.fnal.gov | "I'd rather be grading" From icon-group-sender Mon Dec 13 18:56:28 1993 Received: by cheltenham.cs.arizona.edu; Thu, 16 Dec 1993 08:32:50 MST Date: 13 Dec 93 18:56:28 GMT From: dog.ee.lbl.gov!agate!howland.reston.ans.net!paladin.american.edu!europa.eng.gtefsd.com!news.umbc.edu!eff!news.kei.com!world!ora.com!ruby.ora.com!norm@ucbvax.Berkeley.EDU (Norman Walsh) Organization: O'Reilly and Associates, Inc. Subject: Multiple fonts in vidgets? Message-Id: Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu I've looked at most of the X-Icon example programs and I don't see any way of doing this with vidgets: Is it possible to create vidgets with different fonts? For example, I would like to use one font for button labels, another for messages, another for labels and (yet) another for label entries. Is it possible w/o resorting to doing all the work with primitives? Cheers, norm --- Norman Walsh | Join the club of the Redundancy Club. Production Tools Specialist | O'Reilly & Associates, Inc. | 90 Sherman Street | Cambridge, MA 02140 | (617) 354-5800 | From icon-group-sender Wed Dec 15 20:14:59 1993 Received: by cheltenham.cs.arizona.edu; Thu, 16 Dec 1993 08:33:23 MST Date: Wed, 15 Dec 93 20:14:59 pst From: balexander@ccmail.com Message-Id: <9311157560.AA756015299@smtpgate.ccmail.com> To: agate!howland.reston.ans.net!news.moneng.mei.com!uwm.edu!fnnews.fnal.gov!fnalv.f, icon-group@cs.arizona.edu Subject: Re: Problem for icon mavens Status: R Errors-To: icon-group-errors@cs.arizona.edu Assuming the sorted order, try suspend lim > !L | fail However, I would think that the combination of sorting (order n log n) plus searching (order n) would be worse than simply searching the whole list (order n). So this solution might not be an improvement unless sort-time can be somehow ignored. -- Bob ______________________________ Reply Separator _________________________________ So, icon mavens: What is the clever generation expression which mimics "suspend lim > !L" without actually scanning all of L? -- Michael Glass | Recently not spotted on a bumper sticker: mglass@fnalv.fnal.gov | "I'd rather be grading" From icon-group-sender Wed Dec 15 20:29:55 1993 Received: by cheltenham.cs.arizona.edu; Thu, 16 Dec 1993 08:33:58 MST Date: Wed, 15 Dec 93 20:29:55 pst From: balexander@ccmail.com Message-Id: <9311157560.AA756016195@smtpgate.ccmail.com> To: icon-group@cs.arizona.edu Subject: Re[2]: Need help with (simple?) programming problem. Status: R Errors-To: icon-group-errors@cs.arizona.edu I first sent my hack at this problem only to Mr. Guilmette, but I decided to post it to the 'group since the result turned out especially "cute". I'm not sure this terse solution is quite what he was looking for, but it is kind of interesting (and shorter than Ken Walker's :-) a notable achievement since Ken is a truly top-notch Icon programmer). Another example of one of my favorite Icon techniques: recursive generation (or generative recursion?). procedure main() every write(image(gen(["red ", "green ", "blue "]))) end procedure gen(strings, s, i) /s := "" & i := 1 if i > *strings then return s else every (t := ("" | !strings)) & (not find(t, "" ~== s)) do suspend gen(strings, s || t, i + 1) end _______________________________________________________________________________ > From Ronal F. Guilmette: > > Assume that I have three strings, i.e. "red ", "green ", and "blue ". Now > I want to create a generator which will successively yield each unique > string which contains no more than one instance of each of the original > strings. Here are the string values which should be yielded by the various > invocations/resumptions of the generator: > > "" > "red " > "green " > "blue " > "red green " > "red blue " > "green red " > "green blue " > "blue red " > "blue green " > "red green blue " > "red blue green " > "green red blue " > "green blue red " > "blue red green " > "blue green red " From icon-group-sender Tue Dec 7 01:15:55 1993 Received: by cheltenham.cs.arizona.edu; Thu, 16 Dec 1993 08:34:12 MST Date: 7 Dec 93 01:15:55 GMT From: uchinews!quads!goer@migs.ucar.edu (Richard L. Goerwitz) Organization: University of Chicago Subject: Re: Capsule summary of the ICON language wanted Message-Id: <1993Dec7.011555.14868@midway.uchicago.edu> References: Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Here's the blurb I usually send people. It's not an official description, and probably reflects my own idiosyncratic view- point: Icon (1976) represents a combination of Prolog-like evaluation mechanisms with an Algol-based syntax and SNOBOL-derived string processing facilities. Icon offers automatic storage allocation and garbage collection, as well as built in associative arrays, lists, "real" strings (i.e. not just char arrays), and a data type resembling mathematical sets. Icon is a strongly, though not statically, typed language offering transparent automatic type conversions (i.e. 10, depending on its context, may be converted to "10", etc.) and an elegant string processing mechanism known as "scanning." Central to Icon is the concept of the generator, i.e. the inherent capacity on the part of expressions to produce multiple results. Central also is the notion of goal-directed evaluation - a form of backtracking in which the components of an expression are resumed until some result is achieved, or else the expression as a whole fails. Icon was originally designed by Ralph Griswold, Dave Hanson, and Tim Korb. It was first implemented in C by Steve Wampler. Definitive references: Ralph E. and Madge T. Griswold, _The Icon Programming Language_ (2nd ed.; Prentice Hall, 1989); _The Implementation of the Icon Programming Language_ (Princeton Univ. Pr., 1986). Icon is at its best when used as a prototyping tool, for processing text, for performing various mappings and conversions, and as a general tool for solving problems that tend to require heuristic mechanisms, rather than purely algorithmic ones. In general, Icon's design assigns a higher priority to consistency and lucidity than to functionality within one or another operating environment. For this reason, it is not a good UNIX system administration tool. Nor is it particularly fast. It is a clean, portable system implemented under VMS, MVS, SYSV, Mach, BSD, Ultrix, HP/UX, AI/X, AU/X, and many other operating systems, as well as for various micros, such as the Atari, Mac, and PC. Icon is a good language choice for theorists exploring language design, for scholars in the humanities, and generally for people interested in nonnumeric computing. -- -Richard L. Goerwitz goer%midway@uchicago.bitnet goer@midway.uchicago.edu rutgers!oddjob!ellis!goer From icon-group-sender Thu Dec 16 17:33:48 1993 Received: by cheltenham.cs.arizona.edu; Thu, 16 Dec 1993 23:04:45 MST Date: Thu, 16 Dec 1993 17:33:48 +0700 From: gmt (Gregg Townsend) Message-Id: <9312170033.AA01119@owl.cs.arizona.edu> To: icon-group, norm@ora.com Subject: Re: Multiple fonts in vidgets? Content-Length: 1119 Status: R Errors-To: icon-group-errors@cs.arizona.edu Date: 13 Dec 93 18:56:28 GMT From: Norman Walsh Is it possible to create vidgets with different fonts? For example, I would like to use one font for button labels, another for messages, another for labels and (yet) another for label entries. The trick is to use a new binding for those vidgets. Below is a simplified example without error checking that creates buttons with different fonts. Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 602 621 4325 gmt@cs.arizona.edu 110 57 16 W / 32 13 45 N / +758m ------------------------------------------------------------------------------ link vidgets, vbuttons procedure main() local win, root win := open("buttons", "x") root := Vroot_frame(win) Vbutton(root, 10, 10, win, "one", cb, 1) Vbutton(root, 10, 40, XBind(win, "font=helvetica-bold-14"), "two", cb, 2) Vbutton(root, 10, 70, XBind(win, "font=palatino-roman-14"), "three", cb, 3) Vbutton(root, 10,100, win, "four", cb, 4) VResize(root) GetEvents(root) end procedure cb(vid, val) write("button ", vid.id) end From icon-group-sender Mon Dec 13 23:57:38 1993 Received: by cheltenham.cs.arizona.edu; Thu, 16 Dec 1993 23:05:04 MST Date: 13 Dec 93 23:57:38 GMT From: dog.ee.lbl.gov!overload.lbl.gov!agate!howland.reston.ans.net!sol.ctr.columbia.edu!news.kei.com!world!ksr!tim@ucbvax.Berkeley.EDU (Tim Peters) Organization: Kendall Square Research Corp. Subject: Re: Need help with (simple?) programming problem. Message-Id: <36955@ksr.com> References: Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu rfg@netcom.com (Ronald F. Guilmette) writes: >... >Assume that I have three strings, i.e. "red ", "green ", and "blue ". Now >I want to create a generator which will successively yield each unique >string which contains no more than one instance of each of the original >strings. [should produce:] > > "" > "red " > "green " > "blue " > "red green " > "red blue " > "green red " > "green blue " > "blue red " > "blue green " > "red green blue " > "red blue green " > "green red blue " > "green blue red " > "blue red green " > "blue green red " > >[& order of generation is unimportant] Two hints: 1) A small library of simple combinatorial generators can be combined in powerful ways. For example, your problem can be viewed like this: given a set of strings, generate each permutation of each subset of that set. Given a generator capable of generating subsets, and another capable of generating permutations, you're basically done. 2) Represent the string sets internally as lists of strings, delaying conversion to a string representation until output. The reason is that lists are easy to index and pull apart etc, much easier than reparsing strings all the time. Here's a permutation generator (& no, the generators I'm posting aren't _obvious_ -- but they'll reward the effort of doping them out ): procedure perms( x ) # generate all permutations of list x if *x <= 1 then return x suspend x[1] <-> !x & push( perms(x[2:0]), x[1] ) end And here's a subset generator: procedure subsets( x ) # generate all subsets of list x local head, tail if *x = 0 then return [] head := x[1] tail := x[2:0] suspend subsets(tail) | push(subsets(tail), head) end Now a function to paste a list of strings together: procedure list2str( x ) # e.g., ["a", "bc", "d"] -> "abcd" local answer answer := "" every answer ||:= !x return answer end Then, e.g., procedure main() every write( list2str( perms( subsets( ["red ","green ","blue "] ) ) ) ) end writes [an empty strng was printed on this line] blue green green blue blue green red red blue blue red red green green red red green blue red blue green green red blue green blue red blue green red blue red green Of course you can package the perms+subsets composition in another function, etc. The key idea is just to build it out of simpler generators. >P.S. It probably makes no difference, but in the case of my *real* problem, >one or more of the "original strings" may not actually be strings at all. >They may instead be generators which produce various strings. That may be a lot harder to deal with. If possible, it would probably be best to materialize the sequences into lists, so that they can be fiddled via simple generators like the above. combinatorially y'rs - tim Tim Peters tim@ksr.com not speaking for Kendall Square Research Corp From icon-group-sender Tue Dec 14 00:16:09 1993 Received: by cheltenham.cs.arizona.edu; Thu, 16 Dec 1993 23:05:50 MST Date: 14 Dec 93 00:16:09 GMT From: organpipe.uug.arizona.edu!CS.Arizona.EDU!not-for-mail@uunet.uu.net (Nevin Liber) Organization: University of Arizona CS Department, Tucson AZ Subject: Re: Need help with (simple?) programming problem. Message-Id: <2ej0k9$5jg@caslon.CS.Arizona.EDU> References: Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu In article , Ronald F. Guilmette wrote: |Assume that I have three strings, i.e. "red ", "green ", and "blue ". Now |I want to create a generator which will successively yield each unique |string which contains no more than one instance of each of the original |strings. Here are the string values which should be yielded by the various |invocations/resumptions of the generator: | | "" | "red " | "green " | "blue " | "red green " | "red blue " | "green red " | "green blue " | "blue red " | "blue green " | "red green blue " | "red blue green " | "green red blue " | "green blue red " | "blue red green " | "blue green red " | |After being invoked/resumed 16 times (and yielding each of the above strings |once) the generator should fail. Note that the actual *order* in which the |above strings are yielded is totally unimportant. Any order will do as long |as I get these 16 strings (eventually). |Also note that the ORDER in which the original strings appear in the genera- |ted strings *is* significant. Actually, it isn't. You are just performing a permutation of all possible strings, so the order that the original strings appear in shouldn't matter. Anyway, here is a piece of code to do it: procedure main(LArguments) local SColors SColors := set(["red", "green", "blue" ]) every write(image(Permute(SColors))) end procedure Permute(SSet) local sString every sString := !SSet do { every suspend sString || " " || Permute(delete(copy(SSet), sString)) } return "" end and it produces: "blue red green " "blue red " "blue green red " "blue green " "blue " "red blue green " "red blue " "red green blue " "red green " "red " "green blue red " "green blue " "green red blue " "green red " "green " "" I can't remember if I came up with this algorithm on my own or if I found it in the Icon Program Library (I can't seem to find the IPL on this machine), but I do recall posting an explanation of how this works about a year ago. [Check the archives of the icon group mailing list / comp.lang.icon on cs.arizona.edu for more info.] |(In practice, for |my *real* problem, the number of original strings will in fact be larger |than three... but it *will* be a fixed number (probably less that 12). Actually, the number of strings doesn't matter. __ Nevin ":-)" Liber nevin@cs.arizona.edu (602) 293-2799 ^^^ (520) after 3/95 -- Nevin ":-)" Liber nevin@cs.arizona.edu (602) 293-2799 ^^^ (520) after 3/95 From icon-group-sender Fri Dec 10 03:45:00 1993 Received: by cheltenham.cs.arizona.edu; Wed, 22 Dec 1993 18:07:20 MST Date: 10 Dec 93 03:45:00 GMT From: cis.ohio-state.edu!math.ohio-state.edu!cs.utexas.edu!swrinde!ringer!jeffery@ucbvax.Berkeley.EDU (Clinton L. Jeffery) Organization: Univ of Texas at San Antonio Subject: Re: Uniform graphics functions ? Message-Id: <1993Dec10.034500.22156@ringer.cs.utsa.edu> References: <2e8mvi$jb@canopus.cc.umanitoba.ca> Sender: icon-group-request@cs.arizona.edu To: icon-group@cs.arizona.edu Status: R Errors-To: icon-group-errors@cs.arizona.edu Commenting on Icon's graphics functions rahardj@ccu.umanitoba.ca (Budi Rahardjo) writes: > Are they platform specific ? X-icon looks so X specific.... > Would be nice if there's a common set of functions. Actually, X-Icon is not very X specific at all--the proof is that it was ported virtually in its entirety to OS/2. As we address some remaining portability obstacles (such as font names) and implement Icon's graphics facilities on additional platforms (such as Windows and NT), we are in fact taking the X- off the front of X-Icon, and simply referring to the graphics functions as a part of Icon -- as it becomes available on most platforms, it is becoming part of the mainstream. Now, who wants to help me do the Mac version... Clint Jeffery cjeffery@cs.arizona.edu, jeffery@ringer.cs.utsa.edu The University of Texas at San Antonio -- Clint Jeffery cjeffery@cs.arizona.edu, jeffery@ringer.cs.utsa.edu The University of Texas at San Antonio From icon-group-sender Fri Dec 24 06:27:46 1993 Received: by cheltenham.cs.arizona.edu; Fri, 24 Dec 1993 06:10:08 MST Date: Fri, 24 Dec 1993 06:27:46 -0600 (CST) From: Chris Tenaglia - 257-8765 Subject: Holiday Offering To: icon-group@cs.arizona.edu Message-Id: <01H6UJ39W5GI8WW0B0@mis.mcw.edu> Organization: Medical College of Wisconsin (Milwaukee, WI) X-Vms-To: IN%"icon-group@cs.arizona.edu" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Status: R Errors-To: icon-group-errors@cs.arizona.edu Ho, Ho, Ho, it's that time again. Well this time my offering is a little narrower than normal. It's targetted at BSD flavor unix (i.e. Ultrix). It also uses X-Windows, Icon V8.10. I have a 1280 x 1024 display so I hope it fits on others. This one is called tach.icn and it shows a bunch of analog meters with information related to system performance. I usually invoke it : nice tach & to minimize its system impact because it works off the output of ps -aux which some have told me is intense. If you have SVID or variant, you may need to tweek some things. The source is at the end of this message. If you examine the code you'll see I made some metering vidgets. mopen() for opening a meter object and setmeter() for setting the meter to point to the desired values. Maybe I should have checked the Xipl to see if it's already been done. I guess I just like (re)inventing wheels ;-). Chris Tenaglia (System Manager) | Medical College of Wisconsin 8701 W. Watertown Plank Rd. | Milwaukee, WI 53226 (414)257-8765 | tenaglia@mis.mcw.edu, mcwmis!tenaglia # # file : tach.icn # desc : this program pipes certain system utility outputs into tachometer # style vidgets. # # update by what # 20-nov-1993 tenaglia initial write # procedure main(param) if param[1] == "close" then { mark := open("tach.tmp","w") write(mark,"cancel") close(mark) stop("Sending Cancel Signal.") } CPU := mopen("CPU",500,100) MEM := mopen("MEM",500,250) USR := mopen("USR",500,400) PRO := mopen("PRO",500,550,100,300) &host ? (host := tab(upto('.') | 0)) XGotoXY(CPU[1],33,33) writes(CPU[1],host) XGotoXY(MEM[1],33,33) writes(MEM[1],host) XGotoXY(USR[1],33,33) writes(USR[1],host) XGotoXY(PRO[1],33,33) writes(PRO[1],host) oldcpu := 0 oldmem := 0 oldusr := 0 oldpro := 100 repeat { if (mark := open("tach.tmp")) then { close(CPU[1]) close(MEM[1]) close(USR[1]) close(PRO[1]) close(mark) remove("tach.tmp") remove("tach.ps") stop("Cancel Signal Received.") } # # system("nice ps -aux >tach.ps") (check := open("tach.ps")) | next read(check) | next totcpu := 0 totmem := 0 totpro := 0 while line := read(check) do { numeric(parse(line,' ')[3]) | next totcpu +:= parse(line,' ')[3] totmem +:= parse(line,' ')[4] totpro +:= 1 } close(check) if integer(totcpu) = 0 then next (check := open("who|wc","pr")) | next totusr := parse(read(check),' ')[1] close(check) inc := 0 if oldcpu > totcpu then inc := -1 if oldcpu < totcpu then inc := 1 (inc = 0) | every i := oldcpu to totcpu by inc do setmeter(CPU,i) inc := 0 if oldmem > totmem then inc := -1 if oldmem < totmem then inc := 1 (inc = 0) | every i := oldmem to totmem by inc do setmeter(MEM,i) inc := 0 if oldusr > totusr then inc := -1 if oldusr < totusr then inc := 1 (inc = 0) | every i := oldusr to totusr by inc do setmeter(USR,i) inc := 0 if oldpro > totpro then inc := -1 if oldpro < totpro then inc := 1 (inc = 0) | every i := oldpro to totpro by inc do setmeter(PRO,i) oldcpu := totcpu oldmem := totmem oldusr := totusr oldpro := totpro } end # # parse a string into a list with respect to a delimiter # procedure parse(line,delims) static chars chars := &cset -- delims tokens := [] line ? while tab(upto(chars)) do put(tokens,tab(many(chars))) return tokens end # # # # file : xmeter.inc # desc : vidgets for a dial style meter gauge : # o lst := mopen(label,x,y,min,max,fg,bg) # mopen opens a meter vidget given the label, screen x/y location, # min/max range on the meter face, fore/background colors # a list is returned containing the window handle and the min/max # o setmeter(window,value) # this is used to set the meter needle to a certain reading on the # meter face. # global width, # width of meter height, # height of meter convert, # 2*pi/360 (convert degrees to radians) radius, # radius of dial arc cx, # center x of dial cy, # center y of dial smallest, # smallest angle to begin arc at (degrees) largest # largest angle to end arc at (degrees) procedure mopen(label,x,y,min,max,fg,bg) /label := "Percent" /x := 100 /y := 100 /min := 0 /max := 100 /fg := "white" /bg := "black" ovalue := "" width := 100 height := 100 radius := width / 2 - 10 cx := width / 2 cy := height/ 2 smallest := 315 largest := 45 inc := -1 convert := 3.1415927 * 2.0 / 360.0 rotate := 90*64 gauge := open(label,"x","fg=" || fg,"bg=" || bg, "geometry=" || width || "x" || height || "+" || x || "+" || y, "drawop=xor","linewidth=2") XDrawArc(gauge,10,10,80,80,largest*64-rotate,270*64) angle := smallest * convert posx := sin(angle) * radius + cx posy := cos(angle) * radius + cy XDrawLine(gauge,cx,cy,posx,posy) angle := largest * convert posx := sin(angle) * radius + cx posy := cos(angle) * radius + cy XDrawLine(gauge,cx,cy,posx,posy) XGotoXY(gauge,0,height-10) writes(gauge,min) rs := width - (*largest * 12) XGotoXY(gauge,rs,height-10) writes(gauge,max) return [gauge,min,max,ovalue] end # # # set the meter to a value. by the way, the old needle point has to be # undrawn too. # procedure setmeter(lst,value) window := lst[1] min := lst[2] max := lst[3] ovalue := lst[4] range := max - min span := smallest - largest incr := real(span) / real(range) # # if a line has been drawn, and if the new line isn't at the same position, # then undraw the old line (using xor logic) # if ovalue ~== "" then { if ovalue == value then return angle := convert * (315.0 - (ovalue-min)*incr) posx := sin(angle) * radius + cx posy := cos(angle) * radius + cy XDrawLine(window,cx,cy,posx,posy) XSync(window) } # # beep if the value is out of range # if min > value > max then { write("\7") fail } # # designate the newer value, calculate, draw the setting # don't forget to save the ovalue later for undraw # angle := convert * (315.0 - (value-min)*incr) posx := sin(angle) * radius + cx posy := cos(angle) * radius + cy XDrawLine(window,cx,cy,posx,posy) XGotoXY(window,cx-10,height-10) writes(window,integer(value)," ") XSync(window) lst[4] := value return end