From icon-group-request Mon Feb 6 12:47:47 1995 Received: from optima.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Mon, 6 Feb 1995 13:19:49 MST Received: from agate.Berkeley.EDU by optima.cs.arizona.edu (5.65c/15) via SMTP id AA27423; Mon, 6 Feb 1995 13:19:43 MST Received: by agate.berkeley.edu (8.6.8.1/1.33) id LAA04908; Mon, 6 Feb 1995 11:58:23 -0800 Received: from GATEWAY by agate with netnews for icon-group@cs.arizona.edu (icon-group-l@cs.arizona.edu) To: icon-group-l@cs.arizona.edu Date: 6 Feb 1995 12:47:47 -0700 From: icon-project@cs.arizona.edu Message-Id: <3h5ud3$p63@optima.cs.arizona.edu> Organization: University of Arizona CS Department, Tucson AZ Sender: icon-group-request@cs.arizona.edu Reply-To: icon-project@cs.arizona.edu Subject: Icon Programming Language FAQ Archive-name: comp-lang-icon-faq Posting-Frequency: monthly Frequently Asked Questions About The Icon Programming Language last updated: 01/18/95 This FAQ answers various questions about the Icon programming language, ranging from what it is to how you can get it. This first version of the Icon FAQ is devoted to the issues that are likely to be of most interest to persons who don't know anything about Icon or who are relatively new to it. Future versions of this FAQ will answer questions from more experienced Icon programmers. This FAQ is written by Ralph Griswold with help from Cliff Hathaway, Clint Jeffery, and Gregg Townsend. Section I -- General Questions: I.1. What is Icon? I.2. What is Icon good for? I.3. Where did Icon come from? I.4. What does "Icon" stand for? I.5. On what computers does Icon run? I.6. Who did all these implementations? I.7. Are there other implementations in the works? I.8. Are there different versions of Icon? I.9. Which implementations of Icon have graphics/window capabilities? I.10. Where can I get Icon? I.11. Where can I get documentation about Icon? I.12. How do I get started with Icon? I.13. What is the Icon Project? I.14. Where can I find examples of Icon programs? I.15. What is Idol? I.16. How often is material in Icon's FTP area updated? I.17. How do I stay up to date with what's going on with Icon? I.18. Why isn't the Icon Newsletter available electronically? I.19. Is there a users' group for Icon? I.20. How do I get technical support? I.21. Is there an optimizing compiler for Icon? I.22. What do I need to run the interpreter? I.23. What do I need to run the compiler? I.24. Can I build my own implementation of Icon for a new platform? +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I.1. What is Icon? Icon is a very high level general-purpose programming language with extensive features for processing strings (text) and data structures. Icon is an imperative, procedural language with a syntax that is reminiscent of C and Pascal, but its semantics are at a much higher level than those languages. Icon has a novel expression-evaluation mechanism that integrates goal- directed evaluation and backtracking with conventional control structures. It has a string scanning facility for pattern matching that avoids the tedious details usually associated with analyzing strings. Icon's built-in data structures include sets and tables with associative lookup, lists that can be used as vectors or stacks and queues, and records. Icon is a strongly, though not statically, typed language. It provides transparent automatic type conversion. For example, if an integer is used in an operation that requires a string, the integer is automatically converted to a string. Several implementations of Icon have high-level graphics facilities with an easily programmed window interface. Icon manages storage automatically. Objects are created as needed during program execution and space is reclaimed by garbage collection as needed. The sizes of strings and data structures are limited only by the amount of available memory. I.2. What is Icon good for? As a general-purpose programming language with a large computational repertoire, Icon can be used for most programming tasks. It's at its best when used as a prototyping tool, for processing text, and when ease of programming is needed for experimental and research applications. Paradoxically, Icon is used most often for short, one-shot tasks and for very complex applications. Icon is designed to make programming easy; it emphasizes the value of programmer's time and the importance of getting programs to work quickly. This explains its usefulness for prototyping as well as the apparent paradox of applicability to simple and complex applications. I.3. Where did Icon come from? Icon is the latest in a series of high-level programming languages designed to facilitate programming tasks involving strings and structures. The original language, SNOBOL, was developed at Bell Telephone Laboratories in the early 60s. SNOBOL evolved into SNOBOL4, which is still in use. Subsequent languages were developed at The University of Arizona with support from the National Science Foundation. Incidentally, Icon bears little physical resemblance to SNOBOL4, although it has similar objectives and many similar capabilities. I.4. What does "Icon" stand for? The name Icon (which is not spelled ICON) is not an acronym nor does it stand for anything in particular, although the word iconoclastic was mentioned at the time the name was chosen. The name predates the now common use of "icon" to refer to small images used in graphical user interfaces. This latter usage sometimes causes persons to think mistakenly that Icon is designed to create or manipulate icons. There's not much that can be done about this. I.5. On what computers does Icon run? The implementation of Icon is highly portable. There are versions for the Acorn Archimedes, the Amiga, the Atari ST, IBM CMS and MVS, the Macintosh, MS-DOS, OS/2, UNIX, and VMS. Nearly 60 UNIX platforms are supported. Icon programs also are highly portable. Most Icon programs can run on any platform that supports Icon. I.6. Who did all these implementations? The original implementation of Icon for UNIX was done at The University of Arizona. Most of the other implementations originally were done by volunteers scattered around the world. It's worth noting that all implementations of Icon are based on the same source code, which is written in C. This contributes to the portability of Icon itself, as well as to the portability of programs written in Icon. I.7. Are there other implementations in the works? Yes, work is constantly underway on implementations of Icon for new platforms. Present projects include Windows NT, Win32, and a new Macintosh implementation. I.8. Are there different versions of Icon? Icon has evolved through a series of versions with improved and extended capabilities. The latest major version number is 9. This version includes recent changes and additions, notably in the graphics area. As of this writing, the MS-DOS, UNIX, and VMS implementations are are up to 9.0. Other implementations that presently are at Version 8.10 are being converted to 9.0. There are a few platforms still at 8.0. Almost all programs that run under 8.0 or 8.10 and that do not use graphics will run under 9.0. Programs that use graphics require conversion to 9.0. The 9.0 release provides conversion aids. I.9. Which implementations of Icon have graphics/window capabilities? Icon's graphics facilities presently are supported on the OS/2, UNIX, and VMS implementations. The UNIX and VMS implementations use X, while the OS/2 implementation uses Presentation Manager. The NT and Win32 implementations that are in progress will support Icon's graphics facilities. A Macintosh implementation to support graphics also is in the works. I.10. Where can I get Icon? Most implementations of Icon are available via anonymous FTP to cs.arizona.edu in /icon. The directory /icon/binaries contains executable versions of Icon for several systems, including several popular UNIX platforms. The directory /icon/packages contains source code, test programs, related material, and, most cases, executable binaries as well. All directories have READ.ME files with additional information. Icon also is available on a variety of physical media for prices ranging from $15 to $50. Contact: Icon Project Department of Computer Science The University of Arizona Tucson, AZ 85721 602-621-6613 (voice) 602-621-4246 (fax) icon-orders@cs.arizona.edu (e-mail) Request a copy of the Icon Newsletter for a listing of what's available and what the prices are. Purchases can be made by credit card (MasterCard, Visa, or Discover) or by check drawn on a bank with a branch in the United States and made payable to The University of Arizona. I.11. Where can I get documentation about Icon? The definitive work on Icon is the book The Icon Programming Language, Griswold and Griswold, Prentice-Hall, 1990, 368 pages, ISBN 0-13-447889-4. This book is a complete description and reference manual for Version 8 of Icon. There also is a book on the implementation of Icon: The Implementation of the Icon Programming Language, Griswold and Griswold, Princeton University Press, 1986, 336 pages, ISBN 0-691-08431-9. This book describes the implementation as of Version 6 of Icon. Although the implementation has changed somewhat since then, the basic structure is the same. Technical reports describing recent implementation changes are included with books purchased from the Icon Project. These books are available from the Icon Project or from any book store that handles special orders. Additional documentation is available via FTP in /icon/doc. Notable documents are: TR 90-6 an overview of Icon IPD255 graphics/window facilities IPD236 changes between Versions 8.0 and 9.0 There are manual pages for UNIX systems, but there is no complete on-line documentation. The Icon Newsletter, which includes topical material about Icon and a list of material available from the Icon Project, is published three times a year. Subscriptions are free; contact the Icon Project to get a copy of the latest Newsletter and to be put on the mailing list. The Icon Analyst, a technically oriented newsletter that features articles about programming, is published six times a year. There is a subscription fee for the Analyst. A sample copy is available on request. All back issues of both newsletters are available for purchase. I.12. How do I get started with Icon? If you're a newcomer to Icon, get the package for your platform (by FTP, cd /icon/packages and get READ.ME for more information). This will give you documentation concerning running Icon on your platform, test programs and other material. If the package you pick up does not contain executable files, see /icon/binaries. You also may want to get the overview of Icon: /icon/doc/tr90-6.doc or tr90-6.ps.Z. You'll find pointers to other documents of interest in the package you pick up. I.13. What is the Icon Project? The Icon Project is a name used by the group at The University of Arizona that develops, implements, distributes, and supports the Icon programming language. The Icon Project is not commercial organization. It derives support from The University of Arizona, grants, and (primarily) revenue from the sale of program material and documentation. I.14. Where can I find examples of Icon programs? There is a large program library for Icon. It is an excellent resource for both new and experienced programmers, containing numerous examples of how to do things with Icon. The library also provides many useful applications, as well as hundreds of procedures that supplement Icon's built-in repertoire. The library, like other Icon material, is available via FTP (cd /icon/library) and on physical media from the Icon Project. I.15. What is Idol? Idol is an object-oriented extension to Icon that provides concepts such as classes and multiple inheritance. Idol is written in Idol and is distributed as part of the Icon program library. Idol runs on almost all of the platforms that Icon runs on. Additional Idol information is available from Clint Jeffery, jeffery@ringer.cs.utsa.edu. I.16. How often is material in Icon's FTP area updated? New material is added when it's available. Established implementations usually are only updated when there's a major new release. This typically is every year or two. The Icon program library is updated on a similar schedule. I.17. How do I stay up to date with what's going on with Icon? The best way to find out about developments related to Icon is to subscribe to the Icon Newsletter. It's free, but it is distributed only by postal mail, so you must provide a mailing address. You can stay up to date on the source code, which is changed much more frequently than the version on FTP is updated, by subscribing to the source update service, which provides a new version about three times a year. There also is a subscription service for updates to the Icon program library, which provides new material three or four times a year. See the Icon Newsletter for information about subscribing to these services. I.18. Why isn't the Icon Newsletter available electronically? The Icon Newsletter contains diagrams, images, and other material that cannot be rendered in plain ASCII text. The Newsletter is prepared with a desktop publishing system that produces PostScript, but the files are enormous -- too large to include in the Icon FTP area. Selected articles from the Newsletter are available by FTP in /icon/doc/articles. I.19. Is there a users' group for Icon? There is no official Icon users' group. The Icon Project maintains an electronic mailing list, icon-group@cs.arizona.edu. Mail sent to this address is forwarded to subscribers. To subscribe (or unsubscribe), send a message to icon-group-request@cs.arizona.edu. There is a gateway between icon-group and comp.lang.icon, an unmoderated newsgroup for discussing issues related to Icon. The gateway, which exchanges messages between the two systems, is imperfect and not under the control of the Icon Project. The newsgroup generally provides faster response than the mailing list. The newsgroup is less intrusive, but it sometimes suffers from inappropriate postings. The Icon Project usually sends messages of interest to the Icon community to icon-group. I.20. How do I get technical support? Free technical support is available from the Icon Project via electronic mail to icon-project@cs.arizona.edu or by fax, telephone, and postal mail to the Icon Project as listed above. Since the Icon Project is not a commercial organization, support is limited to what it can provide with its available resources. If the Icon Project cannot help with a problem (such as for a platform it doesn't have), it will attempt to provide a contact with someone who can help. I.21. Is there an optimizing compiler for Icon? Yes. The original implementation was an interpreter. An optimizing compiler was added a few years ago. The interpreter and compiler are largely source-language compatible. The interpreter is used by most Icon programmers because it gets into execution quickly and runs fast enough for most applications. The compiler is best suited for applications that require the fastest possible execution time. In this case, it's generally best to develop the program using the interpreter and then compile the final result for production use. I.22. What do I need to run the interpreter? The Icon interpreter will run on most computers. It requires a reasonable amount of memory, however. Under MS-DOS, the Icon interpreter needs 500KB of application RAM to work well. I.23. What do I need to run the compiler? The Icon compiler is another matter. It requires a C compiler, a fast CPU for tolerable compilation times, a considerable amount of disk space, and a lot of memory -- at least several megabytes. The Icon compiler generates C code, which must then be compiled to produce an executable program. The flexibility that Icon provides to programmers makes compilation technically difficult and the process requires a large amount of memory. The C code it produces is voluminous and stresses the most robust C compilers. Generally speaking, the Icon compiler is practical for platforms in the workstation class but not for most personal computers. Although the compiler can be built and made to run on 286 platforms running standard MS-DOS, only trivially small programs can be compiled. In principle, the Icon compiler is practical on MS-DOS 386/486 platforms with extended memory, but the limited availability of suitable 32-bit C compilers for this environment has discouraged the use of the Icon compiler on such platforms. I.24. Can I build my own implementation of Icon for a new platform? As mentioned above, Icon is written in C and the source code is available via FTP and the Icon Project. The existing implementations are testament to its portability. (a small amount of assembly-language code is required for a context switch, but this is only needed for an optional feature -- co-expressions -- that can be disabled without affecting most of Icon.) New ports involve platform-specific configuration parameters and, in some cases, platform-specific code. The feasibility of a new port and the amount of work it may take depends on the platform -- its architecture, its C compiler, and its environment. Ports to new UNIX platforms generally are easy, although novel architecture may present problems. Ports to new operating systems generally are more difficult, especially if Icon's graphics facilities are implemented. The Icon Project provides what help it can with new ports. In return, it asks that code related to the port to be returned to the Icon Project for inclusion in future versions of the source code for Icon. This makes the new port available to others as well as to the porter when Icon is updated. From icon-group-sender Mon Feb 6 12:47:47 1995 Received: by cheltenham.cs.arizona.edu; Mon, 6 Feb 1995 13:19:51 MST To: icon-group-l@cs.arizona.edu Date: 6 Feb 1995 12:47:47 -0700 From: icon-project@cs.arizona.edu Message-Id: <3h5ud3$p63@optima.cs.arizona.edu> Organization: University of Arizona CS Department, Tucson AZ Sender: icon-group-request@cs.arizona.edu Reply-To: icon-project@cs.arizona.edu Subject: Icon Programming Language FAQ Errors-To: icon-group-errors@cs.arizona.edu Archive-name: comp-lang-icon-faq Posting-Frequency: monthly Frequently Asked Questions About The Icon Programming Language last updated: 01/18/95 This FAQ answers various questions about the Icon programming language, ranging from what it is to how you can get it. This first version of the Icon FAQ is devoted to the issues that are likely to be of most interest to persons who don't know anything about Icon or who are relatively new to it. Future versions of this FAQ will answer questions from more experienced Icon programmers. This FAQ is written by Ralph Griswold with help from Cliff Hathaway, Clint Jeffery, and Gregg Townsend. Section I -- General Questions: I.1. What is Icon? I.2. What is Icon good for? I.3. Where did Icon come from? I.4. What does "Icon" stand for? I.5. On what computers does Icon run? I.6. Who did all these implementations? I.7. Are there other implementations in the works? I.8. Are there different versions of Icon? I.9. Which implementations of Icon have graphics/window capabilities? I.10. Where can I get Icon? I.11. Where can I get documentation about Icon? I.12. How do I get started with Icon? I.13. What is the Icon Project? I.14. Where can I find examples of Icon programs? I.15. What is Idol? I.16. How often is material in Icon's FTP area updated? I.17. How do I stay up to date with what's going on with Icon? I.18. Why isn't the Icon Newsletter available electronically? I.19. Is there a users' group for Icon? I.20. How do I get technical support? I.21. Is there an optimizing compiler for Icon? I.22. What do I need to run the interpreter? I.23. What do I need to run the compiler? I.24. Can I build my own implementation of Icon for a new platform? +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I.1. What is Icon? Icon is a very high level general-purpose programming language with extensive features for processing strings (text) and data structures. Icon is an imperative, procedural language with a syntax that is reminiscent of C and Pascal, but its semantics are at a much higher level than those languages. Icon has a novel expression-evaluation mechanism that integrates goal- directed evaluation and backtracking with conventional control structures. It has a string scanning facility for pattern matching that avoids the tedious details usually associated with analyzing strings. Icon's built-in data structures include sets and tables with associative lookup, lists that can be used as vectors or stacks and queues, and records. Icon is a strongly, though not statically, typed language. It provides transparent automatic type conversion. For example, if an integer is used in an operation that requires a string, the integer is automatically converted to a string. Several implementations of Icon have high-level graphics facilities with an easily programmed window interface. Icon manages storage automatically. Objects are created as needed during program execution and space is reclaimed by garbage collection as needed. The sizes of strings and data structures are limited only by the amount of available memory. I.2. What is Icon good for? As a general-purpose programming language with a large computational repertoire, Icon can be used for most programming tasks. It's at its best when used as a prototyping tool, for processing text, and when ease of programming is needed for experimental and research applications. Paradoxically, Icon is used most often for short, one-shot tasks and for very complex applications. Icon is designed to make programming easy; it emphasizes the value of programmer's time and the importance of getting programs to work quickly. This explains its usefulness for prototyping as well as the apparent paradox of applicability to simple and complex applications. I.3. Where did Icon come from? Icon is the latest in a series of high-level programming languages designed to facilitate programming tasks involving strings and structures. The original language, SNOBOL, was developed at Bell Telephone Laboratories in the early 60s. SNOBOL evolved into SNOBOL4, which is still in use. Subsequent languages were developed at The University of Arizona with support from the National Science Foundation. Incidentally, Icon bears little physical resemblance to SNOBOL4, although it has similar objectives and many similar capabilities. I.4. What does "Icon" stand for? The name Icon (which is not spelled ICON) is not an acronym nor does it stand for anything in particular, although the word iconoclastic was mentioned at the time the name was chosen. The name predates the now common use of "icon" to refer to small images used in graphical user interfaces. This latter usage sometimes causes persons to think mistakenly that Icon is designed to create or manipulate icons. There's not much that can be done about this. I.5. On what computers does Icon run? The implementation of Icon is highly portable. There are versions for the Acorn Archimedes, the Amiga, the Atari ST, IBM CMS and MVS, the Macintosh, MS-DOS, OS/2, UNIX, and VMS. Nearly 60 UNIX platforms are supported. Icon programs also are highly portable. Most Icon programs can run on any platform that supports Icon. I.6. Who did all these implementations? The original implementation of Icon for UNIX was done at The University of Arizona. Most of the other implementations originally were done by volunteers scattered around the world. It's worth noting that all implementations of Icon are based on the same source code, which is written in C. This contributes to the portability of Icon itself, as well as to the portability of programs written in Icon. I.7. Are there other implementations in the works? Yes, work is constantly underway on implementations of Icon for new platforms. Present projects include Windows NT, Win32, and a new Macintosh implementation. I.8. Are there different versions of Icon? Icon has evolved through a series of versions with improved and extended capabilities. The latest major version number is 9. This version includes recent changes and additions, notably in the graphics area. As of this writing, the MS-DOS, UNIX, and VMS implementations are are up to 9.0. Other implementations that presently are at Version 8.10 are being converted to 9.0. There are a few platforms still at 8.0. Almost all programs that run under 8.0 or 8.10 and that do not use graphics will run under 9.0. Programs that use graphics require conversion to 9.0. The 9.0 release provides conversion aids. I.9. Which implementations of Icon have graphics/window capabilities? Icon's graphics facilities presently are supported on the OS/2, UNIX, and VMS implementations. The UNIX and VMS implementations use X, while the OS/2 implementation uses Presentation Manager. The NT and Win32 implementations that are in progress will support Icon's graphics facilities. A Macintosh implementation to support graphics also is in the works. I.10. Where can I get Icon? Most implementations of Icon are available via anonymous FTP to cs.arizona.edu in /icon. The directory /icon/binaries contains executable versions of Icon for several systems, including several popular UNIX platforms. The directory /icon/packages contains source code, test programs, related material, and, most cases, executable binaries as well. All directories have READ.ME files with additional information. Icon also is available on a variety of physical media for prices ranging from $15 to $50. Contact: Icon Project Department of Computer Science The University of Arizona Tucson, AZ 85721 602-621-6613 (voice) 602-621-4246 (fax) icon-orders@cs.arizona.edu (e-mail) Request a copy of the Icon Newsletter for a listing of what's available and what the prices are. Purchases can be made by credit card (MasterCard, Visa, or Discover) or by check drawn on a bank with a branch in the United States and made payable to The University of Arizona. I.11. Where can I get documentation about Icon? The definitive work on Icon is the book The Icon Programming Language, Griswold and Griswold, Prentice-Hall, 1990, 368 pages, ISBN 0-13-447889-4. This book is a complete description and reference manual for Version 8 of Icon. There also is a book on the implementation of Icon: The Implementation of the Icon Programming Language, Griswold and Griswold, Princeton University Press, 1986, 336 pages, ISBN 0-691-08431-9. This book describes the implementation as of Version 6 of Icon. Although the implementation has changed somewhat since then, the basic structure is the same. Technical reports describing recent implementation changes are included with books purchased from the Icon Project. These books are available from the Icon Project or from any book store that handles special orders. Additional documentation is available via FTP in /icon/doc. Notable documents are: TR 90-6 an overview of Icon IPD255 graphics/window facilities IPD236 changes between Versions 8.0 and 9.0 There are manual pages for UNIX systems, but there is no complete on-line documentation. The Icon Newsletter, which includes topical material about Icon and a list of material available from the Icon Project, is published three times a year. Subscriptions are free; contact the Icon Project to get a copy of the latest Newsletter and to be put on the mailing list. The Icon Analyst, a technically oriented newsletter that features articles about programming, is published six times a year. There is a subscription fee for the Analyst. A sample copy is available on request. All back issues of both newsletters are available for purchase. I.12. How do I get started with Icon? If you're a newcomer to Icon, get the package for your platform (by FTP, cd /icon/packages and get READ.ME for more information). This will give you documentation concerning running Icon on your platform, test programs and other material. If the package you pick up does not contain executable files, see /icon/binaries. You also may want to get the overview of Icon: /icon/doc/tr90-6.doc or tr90-6.ps.Z. You'll find pointers to other documents of interest in the package you pick up. I.13. What is the Icon Project? The Icon Project is a name used by the group at The University of Arizona that develops, implements, distributes, and supports the Icon programming language. The Icon Project is not commercial organization. It derives support from The University of Arizona, grants, and (primarily) revenue from the sale of program material and documentation. I.14. Where can I find examples of Icon programs? There is a large program library for Icon. It is an excellent resource for both new and experienced programmers, containing numerous examples of how to do things with Icon. The library also provides many useful applications, as well as hundreds of procedures that supplement Icon's built-in repertoire. The library, like other Icon material, is available via FTP (cd /icon/library) and on physical media from the Icon Project. I.15. What is Idol? Idol is an object-oriented extension to Icon that provides concepts such as classes and multiple inheritance. Idol is written in Idol and is distributed as part of the Icon program library. Idol runs on almost all of the platforms that Icon runs on. Additional Idol information is available from Clint Jeffery, jeffery@ringer.cs.utsa.edu. I.16. How often is material in Icon's FTP area updated? New material is added when it's available. Established implementations usually are only updated when there's a major new release. This typically is every year or two. The Icon program library is updated on a similar schedule. I.17. How do I stay up to date with what's going on with Icon? The best way to find out about developments related to Icon is to subscribe to the Icon Newsletter. It's free, but it is distributed only by postal mail, so you must provide a mailing address. You can stay up to date on the source code, which is changed much more frequently than the version on FTP is updated, by subscribing to the source update service, which provides a new version about three times a year. There also is a subscription service for updates to the Icon program library, which provides new material three or four times a year. See the Icon Newsletter for information about subscribing to these services. I.18. Why isn't the Icon Newsletter available electronically? The Icon Newsletter contains diagrams, images, and other material that cannot be rendered in plain ASCII text. The Newsletter is prepared with a desktop publishing system that produces PostScript, but the files are enormous -- too large to include in the Icon FTP area. Selected articles from the Newsletter are available by FTP in /icon/doc/articles. I.19. Is there a users' group for Icon? There is no official Icon users' group. The Icon Project maintains an electronic mailing list, icon-group@cs.arizona.edu. Mail sent to this address is forwarded to subscribers. To subscribe (or unsubscribe), send a message to icon-group-request@cs.arizona.edu. There is a gateway between icon-group and comp.lang.icon, an unmoderated newsgroup for discussing issues related to Icon. The gateway, which exchanges messages between the two systems, is imperfect and not under the control of the Icon Project. The newsgroup generally provides faster response than the mailing list. The newsgroup is less intrusive, but it sometimes suffers from inappropriate postings. The Icon Project usually sends messages of interest to the Icon community to icon-group. I.20. How do I get technical support? Free technical support is available from the Icon Project via electronic mail to icon-project@cs.arizona.edu or by fax, telephone, and postal mail to the Icon Project as listed above. Since the Icon Project is not a commercial organization, support is limited to what it can provide with its available resources. If the Icon Project cannot help with a problem (such as for a platform it doesn't have), it will attempt to provide a contact with someone who can help. I.21. Is there an optimizing compiler for Icon? Yes. The original implementation was an interpreter. An optimizing compiler was added a few years ago. The interpreter and compiler are largely source-language compatible. The interpreter is used by most Icon programmers because it gets into execution quickly and runs fast enough for most applications. The compiler is best suited for applications that require the fastest possible execution time. In this case, it's generally best to develop the program using the interpreter and then compile the final result for production use. I.22. What do I need to run the interpreter? The Icon interpreter will run on most computers. It requires a reasonable amount of memory, however. Under MS-DOS, the Icon interpreter needs 500KB of application RAM to work well. I.23. What do I need to run the compiler? The Icon compiler is another matter. It requires a C compiler, a fast CPU for tolerable compilation times, a considerable amount of disk space, and a lot of memory -- at least several megabytes. The Icon compiler generates C code, which must then be compiled to produce an executable program. The flexibility that Icon provides to programmers makes compilation technically difficult and the process requires a large amount of memory. The C code it produces is voluminous and stresses the most robust C compilers. Generally speaking, the Icon compiler is practical for platforms in the workstation class but not for most personal computers. Although the compiler can be built and made to run on 286 platforms running standard MS-DOS, only trivially small programs can be compiled. In principle, the Icon compiler is practical on MS-DOS 386/486 platforms with extended memory, but the limited availability of suitable 32-bit C compilers for this environment has discouraged the use of the Icon compiler on such platforms. I.24. Can I build my own implementation of Icon for a new platform? As mentioned above, Icon is written in C and the source code is available via FTP and the Icon Project. The existing implementations are testament to its portability. (a small amount of assembly-language code is required for a context switch, but this is only needed for an optional feature -- co-expressions -- that can be disabled without affecting most of Icon.) New ports involve platform-specific configuration parameters and, in some cases, platform-specific code. The feasibility of a new port and the amount of work it may take depends on the platform -- its architecture, its C compiler, and its environment. Ports to new UNIX platforms generally are easy, although novel architecture may present problems. Ports to new operating systems generally are more difficult, especially if Icon's graphics facilities are implemented. The Icon Project provides what help it can with new ports. In return, it asks that code related to the port to be returned to the Icon Project for inclusion in future versions of the source code for Icon. This makes the new port available to others as well as to the porter when Icon is updated. From icon-group-request Wed Feb 8 23:58:34 1995 Received: from optima.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Wed, 8 Feb 1995 19:20:32 MST Received: from agate.Berkeley.EDU by optima.cs.arizona.edu (5.65c/15) via SMTP id AA24790; Wed, 8 Feb 1995 19:20:29 MST Received: by agate.berkeley.edu (8.6.8.1/1.33) id QAA09253; Wed, 8 Feb 1995 16:44:39 -0800 Received: from GATEWAY by agate with netnews for icon-group@cs.arizona.edu (icon-group-l@cs.arizona.edu) To: icon-group-l@cs.arizona.edu Date: Wed, 8 Feb 1995 23:58:34 GMT From: rpereda@wotangate.sc.ti.com (Ramon Pereda) Message-Id: <1995Feb8.235834.26485@newshost.micro.ti.com> Organization: Texas Instruments Inc. Sender: icon-group-request@cs.arizona.edu References: <3h2gm8$bur@highway.LeidenUniv.nl> Reply-To: rpereda@wotangate.sc.ti.com Subject: Re: emacs and icon Where can I get the emacs setup file for icon called icon.el? --- Ray Pereda rpereda@tools.micro.ti.com From icon-group-sender Wed Feb 8 23:58:34 1995 Received: by cheltenham.cs.arizona.edu; Wed, 8 Feb 1995 19:20:34 MST To: icon-group-l@cs.arizona.edu Date: Wed, 8 Feb 1995 23:58:34 GMT From: rpereda@wotangate.sc.ti.com (Ramon Pereda) Message-Id: <1995Feb8.235834.26485@newshost.micro.ti.com> Organization: Texas Instruments Inc. Sender: icon-group-request@cs.arizona.edu References: <3h2gm8$bur@highway.LeidenUniv.nl> Reply-To: rpereda@wotangate.sc.ti.com Subject: Re: emacs and icon Errors-To: icon-group-errors@cs.arizona.edu Where can I get the emacs setup file for icon called icon.el? --- Ray Pereda rpereda@tools.micro.ti.com From icon-group-request Thu Feb 9 04:51:40 1995 Received: from optima.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Thu, 9 Feb 1995 04:17:37 MST Received: from agate.Berkeley.EDU by optima.cs.arizona.edu (5.65c/15) via SMTP id AA20394; Thu, 9 Feb 1995 04:17:33 MST Received: by agate.berkeley.edu (8.6.8.1/1.33) id BAA25678; Thu, 9 Feb 1995 01:52:10 -0800 Received: from GATEWAY by agate with netnews for icon-group@cs.arizona.edu (icon-group-l@cs.arizona.edu) To: icon-group-l@cs.arizona.edu Date: 9 Feb 1995 04:51:40 -0500 From: ccapc@cyber.sell.com (Consumer Credit Advocates) Message-Id: <3hcojc$f9u@panix.com> Organization: Consumer Credit Advocates, PC Sender: icon-group-request@cs.arizona.edu Subject: GUARANTEED CREDIT REPAIR BY LAW FIRM Consumer Credit Advocates, PC 11 Pennsylvania Plaza, Suite 2101 New York, NY 10001 (212) 629-5261 (telephone) (212) 629-4762 (fax) E-MAIL: ccapc@cyber.sell.com Our LAW FIRM offers direct guaranteed effective credit restoration services by experienced attorneys. THIS IS NOT A DO-IT-YOURSELF KIT. What can we do? We have successfully facilitated the removal of Late Payments, Charge-offs, Foreclosures, Repossessions, Collection Accounts, Loan Defaults, Tax Liens, Judgments and Bankruptcies from our clients' credit reports. WE GUARANTEE THAT YOUR CREDIT CAN BE RESTORED!!! Who needs our services? Anyone who has experienced the inconvenience and embarrassment of being turned down for a credit card, a lease or a purchase of an automobile. Anyone who is unable to buy the house of their dreams due to denial of a mortgage application or who has to pay thousands of dollars more in mortgage interest than someone with good credit. Anyone who has been turned down for a job or promotion due to derogatory credit items on a credit report. Anyone in business who has lost a deal because a person or firm wanted to see his/her credit report before doing business. Anyone who has been unable to establish credit. THE FOUR GREAT MYTHS OF CREDIT: Myth #1: It is illegal or immoral to have your credit report cleared. Fact: It is not illegal nor immoral. In fact, that is what the Fair Credit Reporting Act is all about. The act was enacted by Congress in 1971. One of its purposes as to give consumers the protection of the law and to help guard against any unwarranted invasion of a consumer's right to privacy. Myth #2: The information on a credit report cannot be changed. Fact: Actually, the opposite is true under the Fair Credit Reporting Act. Federal and State laws require that items be removed if they are not 100% accurate or cannot be verified in a timely manner. Myth #3: It is impossible to get a bankruptcy off a credit report. Fact: Bankruptcies can come off credit reports like any other derogatory item. The nature of the derogatory item has nothing to do with its removal under the Fair Credit Reporting Act. Myth #4: Credit Reporting Agencies are empowered with some kind of governmental authority. Fact: Absolutely Not!! They are simply large corporations whose primary goal is to make a profit like any other business. If you have ever applied for or received credit, a file exists in one or more of the credit bureaus. These companies collect, store and distribute as much credit information as they can find, retaining negative information on a credit report for 7 to 10 years. This information is evaluated by potential creditors to determine your credit worthiness. Credit reporting agencies are in business to protect the interests of the creditors. the LAW FIRM's goal is to help and protect the individual consumer from inaccurate credit reporting. The president of our LAW FIRM has been practicing consumer law since 1984. The staff of our firm has successfully processed, disputed and challenged thousands of client credit reports. Our legal fee is based o the number of negative items that appear on a client's credit reports, issued b the three national credit bureaus. Our retainer agreement offers a MONEY BACK GUARANTEE stating that if any negative item is not deleted, upgraded or corrected from a client's credit file, it will give the client a full refund for that item or continue to process the client's file at no additional fee until that item is corrected, upgraded or deleted. THE ONLY THING YOU HAVE TO LOSE IS YOUR BAD CREDIT!! PLEASE CONTACT THE LAW FIRM AND LEAVE YOUR FULL NAME, MAILING ADDRESS AND TELEPHONE NUMBER SO WE MAY FORWARD FURTHER INFORMATION AND INSTRUCTIONS TO YOU ABOUT OUR SERVICE. Consumer Credit Advocates, PC 11 Pennsylvania Plaza, Suite 2101 New York, NY 10001 (212) 629-5261 (telephone) (212) 629-4762 (fax) E-MAIL: ccapc@cyber.sell.com From icon-group-sender Thu Feb 9 04:51:40 1995 Received: by cheltenham.cs.arizona.edu; Thu, 9 Feb 1995 04:17:41 MST To: icon-group-l@cs.arizona.edu Date: 9 Feb 1995 04:51:40 -0500 From: ccapc@cyber.sell.com (Consumer Credit Advocates) Message-Id: <3hcojc$f9u@panix.com> Organization: Consumer Credit Advocates, PC Sender: icon-group-request@cs.arizona.edu Subject: GUARANTEED CREDIT REPAIR BY LAW FIRM Errors-To: icon-group-errors@cs.arizona.edu Consumer Credit Advocates, PC 11 Pennsylvania Plaza, Suite 2101 New York, NY 10001 (212) 629-5261 (telephone) (212) 629-4762 (fax) E-MAIL: ccapc@cyber.sell.com Our LAW FIRM offers direct guaranteed effective credit restoration services by experienced attorneys. THIS IS NOT A DO-IT-YOURSELF KIT. What can we do? We have successfully facilitated the removal of Late Payments, Charge-offs, Foreclosures, Repossessions, Collection Accounts, Loan Defaults, Tax Liens, Judgments and Bankruptcies from our clients' credit reports. WE GUARANTEE THAT YOUR CREDIT CAN BE RESTORED!!! Who needs our services? Anyone who has experienced the inconvenience and embarrassment of being turned down for a credit card, a lease or a purchase of an automobile. Anyone who is unable to buy the house of their dreams due to denial of a mortgage application or who has to pay thousands of dollars more in mortgage interest than someone with good credit. Anyone who has been turned down for a job or promotion due to derogatory credit items on a credit report. Anyone in business who has lost a deal because a person or firm wanted to see his/her credit report before doing business. Anyone who has been unable to establish credit. THE FOUR GREAT MYTHS OF CREDIT: Myth #1: It is illegal or immoral to have your credit report cleared. Fact: It is not illegal nor immoral. In fact, that is what the Fair Credit Reporting Act is all about. The act was enacted by Congress in 1971. One of its purposes as to give consumers the protection of the law and to help guard against any unwarranted invasion of a consumer's right to privacy. Myth #2: The information on a credit report cannot be changed. Fact: Actually, the opposite is true under the Fair Credit Reporting Act. Federal and State laws require that items be removed if they are not 100% accurate or cannot be verified in a timely manner. Myth #3: It is impossible to get a bankruptcy off a credit report. Fact: Bankruptcies can come off credit reports like any other derogatory item. The nature of the derogatory item has nothing to do with its removal under the Fair Credit Reporting Act. Myth #4: Credit Reporting Agencies are empowered with some kind of governmental authority. Fact: Absolutely Not!! They are simply large corporations whose primary goal is to make a profit like any other business. If you have ever applied for or received credit, a file exists in one or more of the credit bureaus. These companies collect, store and distribute as much credit information as they can find, retaining negative information on a credit report for 7 to 10 years. This information is evaluated by potential creditors to determine your credit worthiness. Credit reporting agencies are in business to protect the interests of the creditors. the LAW FIRM's goal is to help and protect the individual consumer from inaccurate credit reporting. The president of our LAW FIRM has been practicing consumer law since 1984. The staff of our firm has successfully processed, disputed and challenged thousands of client credit reports. Our legal fee is based o the number of negative items that appear on a client's credit reports, issued b the three national credit bureaus. Our retainer agreement offers a MONEY BACK GUARANTEE stating that if any negative item is not deleted, upgraded or corrected from a client's credit file, it will give the client a full refund for that item or continue to process the client's file at no additional fee until that item is corrected, upgraded or deleted. THE ONLY THING YOU HAVE TO LOSE IS YOUR BAD CREDIT!! PLEASE CONTACT THE LAW FIRM AND LEAVE YOUR FULL NAME, MAILING ADDRESS AND TELEPHONE NUMBER SO WE MAY FORWARD FURTHER INFORMATION AND INSTRUCTIONS TO YOU ABOUT OUR SERVICE. Consumer Credit Advocates, PC 11 Pennsylvania Plaza, Suite 2101 New York, NY 10001 (212) 629-5261 (telephone) (212) 629-4762 (fax) E-MAIL: ccapc@cyber.sell.com From icon-group-request Thu Feb 9 15:02:26 1995 Received: from optima.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Thu, 9 Feb 1995 09:18:24 MST Received: from agate.Berkeley.EDU by optima.cs.arizona.edu (5.65c/15) via SMTP id AA00206; Thu, 9 Feb 1995 09:18:22 MST Received: by agate.berkeley.edu (8.6.8.1/1.33) id HAA04728; Thu, 9 Feb 1995 07:13:58 -0800 Received: from GATEWAY by agate with netnews for icon-group@cs.arizona.edu (icon-group-l@cs.arizona.edu) To: icon-group-l@cs.arizona.edu Date: Thu, 9 Feb 1995 15:02:26 GMT From: dkuhlman@netcom.com (G. David Kuhlman) Message-Id: Organization: NETCOM On-line Communication Services (408 261-4700 guest) Sender: icon-group-request@cs.arizona.edu Subject: Doc on icon compiler? Where can I find a document on how to use the Icon compiler (Icon --> C). I think it's IPD214 (?), but I couldn't find it on the ftp site. I have a medium size program that runs fine under the interpreter (OS/2 and Linux), but gives an error message and exits when compiled to C (under Linux). I need to learn how to track down the problem. Thanks. -- ---------------------- Dave Kuhlman Reify, Redwood City, CA Internet: dkuhlman@netcom.com ---------------------- From icon-group-sender Thu Feb 9 15:02:26 1995 Received: by cheltenham.cs.arizona.edu; Thu, 9 Feb 1995 09:18:25 MST To: icon-group-l@cs.arizona.edu Date: Thu, 9 Feb 1995 15:02:26 GMT From: dkuhlman@netcom.com (G. David Kuhlman) Message-Id: Organization: NETCOM On-line Communication Services (408 261-4700 guest) Sender: icon-group-request@cs.arizona.edu Subject: Doc on icon compiler? Errors-To: icon-group-errors@cs.arizona.edu Where can I find a document on how to use the Icon compiler (Icon --> C). I think it's IPD214 (?), but I couldn't find it on the ftp site. I have a medium size program that runs fine under the interpreter (OS/2 and Linux), but gives an error message and exits when compiled to C (under Linux). I need to learn how to track down the problem. Thanks. -- ---------------------- Dave Kuhlman Reify, Redwood City, CA Internet: dkuhlman@netcom.com ---------------------- From cliff Thu Feb 9 09:35:36 1995 Date: Thu, 9 Feb 1995 09:35:36 MST From: "Cliff Hathaway" Message-Id: <199502091635.AA23519@cheltenham.cs.arizona.edu> Received: by cheltenham.cs.arizona.edu; Thu, 9 Feb 1995 09:35:36 MST To: icon-group Subject: Re: Doc on icon compiler? > From: dkuhlman@netcom.com (G. David Kuhlman) > Subject: Doc on icon compiler? > > Where can I find a document on how to use the Icon > compiler (Icon --> C). I think it's IPD214 (?), but > I couldn't find it on the ftp site. > > I have a medium size program that runs fine under the > interpreter (OS/2 and Linux), but gives an error message > and exits when compiled to C (under Linux). I need to > learn how to track down the problem. > > Thanks. > > -- > ---------------------- > Dave Kuhlman > Reify, Redwood City, CA > Internet: dkuhlman@netcom.com > ---------------------- > ftp.cs.arizona.edu:/icon/doc/ipd237.{doc,ps.Z} discusses version 9.0 of the Icon compiler. cliff From icon-group-sender Thu Feb 9 09:35:36 1995 Received: by cheltenham.cs.arizona.edu; Thu, 9 Feb 1995 09:35:37 MST Date: Thu, 9 Feb 1995 09:35:36 MST From: "Cliff Hathaway" Message-Id: <199502091635.AA23519@cheltenham.cs.arizona.edu> To: icon-group Subject: Re: Doc on icon compiler? Errors-To: icon-group-errors@cs.arizona.edu > From: dkuhlman@netcom.com (G. David Kuhlman) > Subject: Doc on icon compiler? > > Where can I find a document on how to use the Icon > compiler (Icon --> C). I think it's IPD214 (?), but > I couldn't find it on the ftp site. > > I have a medium size program that runs fine under the > interpreter (OS/2 and Linux), but gives an error message > and exits when compiled to C (under Linux). I need to > learn how to track down the problem. > > Thanks. > > -- > ---------------------- > Dave Kuhlman > Reify, Redwood City, CA > Internet: dkuhlman@netcom.com > ---------------------- > ftp.cs.arizona.edu:/icon/doc/ipd237.{doc,ps.Z} discusses version 9.0 of the Icon compiler. cliff From cargo@ironwood.cray.com Thu Feb 9 10:46:19 1995 Received: from optima.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Thu, 9 Feb 1995 09:46:27 MST Received: from timbuk.cray.com by optima.cs.arizona.edu (5.65c/15) via SMTP id AA01704; Thu, 9 Feb 1995 09:46:23 MST Received: from sdiv.cray.com (ironwood.cray.com [128.162.21.36]) by timbuk.cray.com (8.6.9/CRI-fence-1.4) with SMTP id KAA03025 for ; Thu, 9 Feb 1995 10:46:21 -0600 Received: from fir121 by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA12841; Thu, 9 Feb 1995 10:46:20 -0600 From: cargo@ironwood.cray.com (David Cargo) Received: by fir121 (5.0/btd-b3) id AA02575; Thu, 9 Feb 1995 10:46:19 -0600 Message-Id: <9502091646.AA02575@fir121> Date: Thu, 9 Feb 1995 10:46:19 -0600 To: icon-group@cs.arizona.edu Subject: string invocation example X-Mailer: [XMailTool v3.1.0] Content-Length: 1658 The February Icon Analyst has a cover article about string invocation. I wrote this program to take advantage of string invocation for filtering text files in a flexible fashion. ############################################################################ # # File: filter.icn # # Subject: Program to apply Icon functions to lines of input # # Author: David S. Cargo # # Date: February 9, 1995 # ############################################################################ # # Version: 1.1 # ############################################################################ # # This program uses string invocation to apply an Icon function to lines # of input to produce lines of output. # # ############################################################################ # # Links: none # # Requires: string invocation # ############################################################################ procedure main(args) local arglist, function_name, line (*args > 0) | Usage() function_name := get(args) (function_name == function()) | possible_match(function_name) if *args = 0 then while line := read() do write(function_name(line)) else { arglist := [] ||| args while arglist[1] := read() do write(function_name!arglist) } return end procedure Usage() every write(function()) stop("Usage: filter functionname [arg1 [arg2 ...]] stdout") end procedure possible_match(function_name) local fname write(image(function_name), " is not the name of any function.") every fname := function() do if find(function_name, fname) then write(fname) stop() end From icon-group-sender Thu Feb 9 10:46:19 1995 Received: by cheltenham.cs.arizona.edu; Thu, 9 Feb 1995 09:46:28 MST From: cargo@ironwood.cray.com (David Cargo) Message-Id: <9502091646.AA02575@fir121> Date: Thu, 9 Feb 1995 10:46:19 -0600 To: icon-group@cs.arizona.edu Subject: string invocation example X-Mailer: [XMailTool v3.1.0] Content-Length: 1658 Errors-To: icon-group-errors@cs.arizona.edu The February Icon Analyst has a cover article about string invocation. I wrote this program to take advantage of string invocation for filtering text files in a flexible fashion. ############################################################################ # # File: filter.icn # # Subject: Program to apply Icon functions to lines of input # # Author: David S. Cargo # # Date: February 9, 1995 # ############################################################################ # # Version: 1.1 # ############################################################################ # # This program uses string invocation to apply an Icon function to lines # of input to produce lines of output. # # ############################################################################ # # Links: none # # Requires: string invocation # ############################################################################ procedure main(args) local arglist, function_name, line (*args > 0) | Usage() function_name := get(args) (function_name == function()) | possible_match(function_name) if *args = 0 then while line := read() do write(function_name(line)) else { arglist := [] ||| args while arglist[1] := read() do write(function_name!arglist) } return end procedure Usage() every write(function()) stop("Usage: filter functionname [arg1 [arg2 ...]] stdout") end procedure possible_match(function_name) local fname write(image(function_name), " is not the name of any function.") every fname := function() do if find(function_name, fname) then write(fname) stop() end From cargo@ironwood.cray.com Thu Feb 9 13:23:58 1995 Received: from optima.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Thu, 9 Feb 1995 12:58:39 MST Received: from timbuk.cray.com by optima.cs.arizona.edu (5.65c/15) via SMTP id AA11254; Thu, 9 Feb 1995 12:58:37 MST Received: from sdiv.cray.com (ironwood.cray.com [128.162.21.36]) by timbuk.cray.com (8.6.9/CRI-fence-1.4) with SMTP id NAA22970 for ; Thu, 9 Feb 1995 13:24:00 -0600 Received: from fir121 by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AA03395; Thu, 9 Feb 1995 13:23:59 -0600 From: cargo@ironwood.cray.com (David Cargo) Received: by fir121 (5.0/btd-b3) id AA02772; Thu, 9 Feb 1995 13:23:58 -0600 Message-Id: <9502091923.AA02772@fir121> Date: Thu, 9 Feb 1995 13:23:58 -0600 To: icon-group@cs.arizona.edu Subject: string invocation example X-Mailer: [XMailTool v3.1.0] Content-Length: 1565 Of course I found a bug in the code I sent out. Here's a revised version. ############################################################################ # # File: filter.icn # # Subject: Program to apply Icon functions to lines of input # # Author: David S. Cargo # # Date: February 9, 1995 # ############################################################################ # # Version: 1.2 # ############################################################################ # # This program uses string invocation to apply an Icon function to lines # of input to produce lines of output. # ############################################################################ # # Links: none # # Requires: string invocation # ############################################################################ invocable all procedure main(args) local arglist, function_name, line (*args > 0) | Usage() function_name := get(args) (function_name == function()) | possible_match(function_name) if *args = 0 then while line := read() do write(function_name(line)) else { arglist := [""] ||| args while arglist[1] := read() do write(function_name!arglist) } return end procedure Usage() every write(function()) stop("Usage: filter functionname [arg1 [arg2 ...]] stdout") end procedure possible_match(function_name) local fname write(image(function_name), " is not the name of any function.") every fname := function() do if find(function_name, fname) then write(fname) stop() end From ralph Fri Feb 10 05:51:22 1995 Date: Fri, 10 Feb 1995 05:51:22 MST From: "Ralph Griswold" Message-Id: <199502101251.AA18625@cheltenham.cs.arizona.edu> Received: by cheltenham.cs.arizona.edu; Fri, 10 Feb 1995 05:51:22 MST To: icon-group Subject: Postings to icon-group Our icon-group news group presently is unmoderated. This means that anything anyone posts to it goes to all subscribers. Recently commercial advertisements have been broadcast indiscriminately and have wound up in icon-group. This problem is only going to get worse as use of Internet increases. Moderating icon-group takes time and effort and also delays message distribution, but we may have no other choice. Until we work something out, please try to put up with an occasional inapproproate posting. 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-4246 (fax) From icon-group-request Mon Feb 13 16:08:32 1995 Received: from optima.CS.Arizona.EDU by cheltenham.CS.Arizona.EDU; Mon, 13 Feb 1995 11:17:20 MST Received: from agate.Berkeley.EDU by optima.cs.arizona.edu (5.65c/15) via SMTP id AA03752; Mon, 13 Feb 1995 11:17:15 MST Received: by agate.berkeley.edu (8.6.8.1/1.33) id JAA08257; Mon, 13 Feb 1995 09:30:46 -0800 Received: from GATEWAY by agate with netnews for icon-group@cs.arizona.edu (icon-group-l@cs.arizona.edu) To: icon-group-l@cs.arizona.edu Date: 13 Feb 1995 16:08:32 GMT From: ruiter@ruls41.fsw.LeidenUniv.nl (Jan-Peter de Ruiter) Message-Id: <3ho060$k6k@highway.LeidenUniv.nl> Organization: Leiden University, The Netherlands Sender: icon-group-request@cs.arizona.edu Subject: icon-describe mode problem Hi, I'm having a problem with icon-describe.el, that is supposed to give documentation about the icon word near the point in emacs. If I put the point at either of the following positions relative to the word 'push': push ^ ^^^^^^^^ ^ I still have to enter the word I want documentation about. Given that this test (example) is taken straight out of the documentation of emacs-describe.el, I wonder what's wrong. Anyone to rescue? JP From cliff Wed May 17 16:38:57 1995 To: /usr/icon/icon-group/mail Subject: Icon-group mailing list You have been added to the Icon-Group list. This mailing list is meant to be a common meeting area for persons interested in the Icon programming language. Topics for discussion include (but are not limited to): Programming Techniques - Style - Efficiency - Idioms - Pros and Cons of certain constructs - Clever ways to accomplish a certain task Theoretical Aspects Icon in relation to other languages Applications of Icon Implementation Issues Porting Icon to other machines History/Origins Idea/Wish Lists Announcement/Exchange of programs and procedures Bugs Items of interest should be mailed to icon-group@cs.arizona.edu. Mail is redistributed to all persons on the list. It's good practice to include a signature giving your name and email address, because not all mailers preserve these. Requests for addition or removal from the list should be sent to icon-group-request@cs.arizona.edu. This mailing list does not subsume the function of the icon-project mailbox that we currently maintain. Rather, the mailing list supplements it. Icon questions that may not be appropriate for icon-group can be sent to icon-project. If you are in doubt, send to icon-project, note your uncertainty, and we'll see it ends up in the correct place. If you submit an item to Icon-Group and get back failure notifications for individuals, you can help eliminate this problem by mailing such messages to icon-group-REQUEST. (Our software tries to arrange for failure notifications to be sent to us, but it's a moving target type problem.) A copy of the Frequently Asked Questions (and Answers) for the Icon Programming Language will be sent as a separate message. From cliff Wed May 17 16:38:57 1995 To: /usr/icon/icon-group/mail Subject: Icon-group FAQ Frequently Asked Questions About The Icon Programming Language last updated: 01/18/95 This FAQ answers various questions about the Icon programming language, ranging from what it is to how you can get it. This first version of the Icon FAQ is devoted to the issues that are likely to be of most interest to persons who don't know anything about Icon or who are relatively new to it. Future versions of this FAQ will answer questions from more experienced Icon programmers. This FAQ is written by Ralph Griswold with help from Cliff Hathaway, Clint Jeffery, and Gregg Townsend. Section I -- General Questions: I.1. What is Icon? I.2. What is Icon good for? I.3. Where did Icon come from? I.4. What does "Icon" stand for? I.5. On what computers does Icon run? I.6. Who did all these implementations? I.7. Are there other implementations in the works? I.8. Are there different versions of Icon? I.9. Which implementations of Icon have graphics/window capabilities? I.10. Where can I get Icon? I.11. Where can I get documentation about Icon? I.12. How do I get started with Icon? I.13. What is the Icon Project? I.14. Where can I find examples of Icon programs? I.15. What is Idol? I.16. How often is material in Icon's FTP area updated? I.17. How do I stay up to date with what's going on with Icon? I.18. Why isn't the Icon Newsletter available electronically? I.19. Is there a users' group for Icon? I.20. How do I get technical support? I.21. Is there an optimizing compiler for Icon? I.22. What do I need to run the interpreter? I.23. What do I need to run the compiler? I.24. Can I build my own implementation of Icon for a new platform? +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I.1. What is Icon? Icon is a very high level general-purpose programming language with extensive features for processing strings (text) and data structures. Icon is an imperative, procedural language with a syntax that is reminiscent of C and Pascal, but its semantics are at a much higher level than those languages. Icon has a novel expression-evaluation mechanism that integrates goal- directed evaluation and backtracking with conventional control structures. It has a string scanning facility for pattern matching that avoids the tedious details usually associated with analyzing strings. Icon's built-in data structures include sets and tables with associative lookup, lists that can be used as vectors or stacks and queues, and records. Icon is a strongly, though not statically, typed language. It provides transparent automatic type conversion. For example, if an integer is used in an operation that requires a string, the integer is automatically converted to a string. Several implementations of Icon have high-level graphics facilities with an easily programmed window interface. Icon manages storage automatically. Objects are created as needed during program execution and space is reclaimed by garbage collection as needed. The sizes of strings and data structures are limited only by the amount of available memory. I.2. What is Icon good for? As a general-purpose programming language with a large computational repertoire, Icon can be used for most programming tasks. It's at its best when used as a prototyping tool, for processing text, and when ease of programming is needed for experimental and research applications. Paradoxically, Icon is used most often for short, one-shot tasks and for very complex applications. Icon is designed to make programming easy; it emphasizes the value of programmer's time and the importance of getting programs to work quickly. This explains its usefulness for prototyping as well as the apparent paradox of applicability to simple and complex applications. I.3. Where did Icon come from? Icon is the latest in a series of high-level programming languages designed to facilitate programming tasks involving strings and structures. The original language, SNOBOL, was developed at Bell Telephone Laboratories in the early 60s. SNOBOL evolved into SNOBOL4, which is still in use. Subsequent languages were developed at The University of Arizona with support from the National Science Foundation. Incidentally, Icon bears little physical resemblance to SNOBOL4, although it has similar objectives and many similar capabilities. I.4. What does "Icon" stand for? The name Icon (which is not spelled ICON) is not an acronym nor does it stand for anything in particular, although the word iconoclastic was mentioned at the time the name was chosen. The name predates the now common use of "icon" to refer to small images used in graphical user interfaces. This latter usage sometimes causes persons to think mistakenly that Icon is designed to create or manipulate icons. There's not much that can be done about this. I.5. On what computers does Icon run? The implementation of Icon is highly portable. There are versions for the Acorn Archimedes, the Amiga, the Atari ST, IBM CMS and MVS, the Macintosh, MS-DOS, OS/2, UNIX, and VMS. Nearly 60 UNIX platforms are supported. Icon programs also are highly portable. Most Icon programs can run on any platform that supports Icon. I.6. Who did all these implementations? The original implementation of Icon for UNIX was done at The University of Arizona. Most of the other implementations originally were done by volunteers scattered around the world. It's worth noting that all implementations of Icon are based on the same source code, which is written in C. This contributes to the portability of Icon itself, as well as to the portability of programs written in Icon. I.7. Are there other implementations in the works? Yes, work is constantly underway on implementations of Icon for new platforms. Present projects include Windows NT, Win32, and a new Macintosh implementation. I.8. Are there different versions of Icon? Icon has evolved through a series of versions with improved and extended capabilities. The latest major version number is 9. This version includes recent changes and additions, notably in the graphics area. As of this writing, the MS-DOS, UNIX, and VMS implementations are are up to 9.0. Other implementations that presently are at Version 8.10 are being converted to 9.0. There are a few platforms still at 8.0. Almost all programs that run under 8.0 or 8.10 and that do not use graphics will run under 9.0. Programs that use graphics require conversion to 9.0. The 9.0 release provides conversion aids. I.9. Which implementations of Icon have graphics/window capabilities? Icon's graphics facilities presently are supported on the OS/2, UNIX, and VMS implementations. The UNIX and VMS implementations use X, while the OS/2 implementation uses Presentation Manager. The NT and Win32 implementations that are in progress will support Icon's graphics facilities. A Macintosh implementation to support graphics also is in the works. I.10. Where can I get Icon? Most implementations of Icon are available via anonymous FTP to ftp.cs.arizona.edu in /icon. The directory /icon/binaries contains executable versions of Icon for several systems, including several popular UNIX platforms. The directory /icon/packages contains source code, test programs, related material, and, most cases, executable binaries as well. All directories have READ.ME files with additional information. Icon also is available on a variety of physical media for prices ranging from $15 to $50. Contact: Icon Project Department of Computer Science The University of Arizona Tucson, AZ 85721 520-621-6613 (voice) 520-621-4246 (fax) icon-orders@cs.arizona.edu (e-mail) Request a copy of the Icon Newsletter for a listing of what's available and what the prices are. Purchases can be made by credit card (MasterCard, Visa, or Discover) or by check drawn on a bank with a branch in the United States and made payable to The University of Arizona. I.11. Where can I get documentation about Icon? The definitive work on Icon is the book The Icon Programming Language, Griswold and Griswold, Prentice-Hall, 1990, 368 pages, ISBN 0-13-447889-4. This book is a complete description and reference manual for Version 8 of Icon. There also is a book on the implementation of Icon: The Implementation of the Icon Programming Language, Griswold and Griswold, Princeton University Press, 1986, 336 pages, ISBN 0-691-08431-9. This book describes the implementation as of Version 6 of Icon. Although the implementation has changed somewhat since then, the basic structure is the same. Technical reports describing recent implementation changes are included with books purchased from the Icon Project. These books are available from the Icon Project or from any book store that handles special orders. Additional documentation is available via FTP in /icon/doc. Notable documents are: TR 90-6 an overview of Icon IPD255 graphics/window facilities IPD236 changes between Versions 8.0 and 9.0 There are manual pages for UNIX systems, but there is no complete on-line documentation. The Icon Newsletter, which includes topical material about Icon and a list of material available from the Icon Project, is published three times a year. Subscriptions are free; contact the Icon Project to get a copy of the latest Newsletter and to be put on the mailing list. The Icon Analyst, a technically oriented newsletter that features articles about programming, is published six times a year. There is a subscription fee for the Analyst. A sample copy is available on request. All back issues of both newsletters are available for purchase. I.12. How do I get started with Icon? If you're a newcomer to Icon, get the package for your platform (by FTP, cd /icon/packages and get READ.ME for more information). This will give you documentation concerning running Icon on your platform, test programs and other material. If the package you pick up does not contain executable files, see /icon/binaries. You also may want to get the overview of Icon: /icon/doc/tr90-6.doc or tr90-6.ps.Z. You'll find pointers to other documents of interest in the package you pick up. I.13. What is the Icon Project? The Icon Project is a name used by the group at The University of Arizona that develops, implements, distributes, and supports the Icon programming language. The Icon Project is not commercial organization. It derives support from The University of Arizona, grants, and (primarily) revenue from the sale of program material and documentation. I.14. Where can I find examples of Icon programs? There is a large program library for Icon. It is an excellent resource for both new and experienced programmers, containing numerous examples of how to do things with Icon. The library also provides many useful applications, as well as hundreds of procedures that supplement Icon's built-in repertoire. The library, like other Icon material, is available via FTP (cd /icon/library) and on physical media from the Icon Project. I.15. What is Idol? Idol is an object-oriented extension to Icon that provides concepts such as classes and multiple inheritance. Idol is written in Idol and is distributed as part of the Icon program library. Idol runs on almost all of the platforms that Icon runs on. Additional Idol information is available from Clint Jeffery, jeffery@ringer.cs.utsa.edu. I.16. How often is material in Icon's FTP area updated? New material is added when it's available. Established implementations usually are only updated when there's a major new release. This typically is every year or two. The Icon program library is updated on a similar schedule. I.17. How do I stay up to date with what's going on with Icon? The best way to find out about developments related to Icon is to subscribe to the Icon Newsletter. It's free, but it is distributed only by postal mail, so you must provide a mailing address. You can stay up to date on the source code, which is changed much more frequently than the version on FTP is updated, by subscribing to the source update service, which provides a new version about three times a year. There also is a subscription service for updates to the Icon program library, which provides new material three or four times a year. See the Icon Newsletter for information about subscribing to these services. I.18. Why isn't the Icon Newsletter available electronically? The Icon Newsletter contains diagrams, images, and other material that cannot be rendered in plain ASCII text. The Newsletter is prepared with a desktop publishing system that produces PostScript, but the files are enormous -- too large to include in the Icon FTP area. Selected articles from the Newsletter are available by FTP in /icon/doc/articles. I.19. Is there a users' group for Icon? There is no official Icon users' group. The Icon Project maintains an electronic mailing list, icon-group@cs.arizona.edu. Mail sent to this address is forwarded to subscribers. To subscribe (or unsubscribe), send a message to icon-group-request@cs.arizona.edu. There is a gateway between icon-group and comp.lang.icon, an unmoderated newsgroup for discussing issues related to Icon. The gateway, which exchanges messages between the two systems, is imperfect and not under the control of the Icon Project. The newsgroup generally provides faster response than the mailing list. The newsgroup is less intrusive, but it sometimes suffers from inappropriate postings. The Icon Project usually sends messages of interest to the Icon community to icon-group. I.20. How do I get technical support? Free technical support is available from the Icon Project via electronic mail to icon-project@cs.arizona.edu or by fax, telephone, and postal mail to the Icon Project as listed above. Since the Icon Project is not a commercial organization, support is limited to what it can provide with its available resources. If the Icon Project cannot help with a problem (such as for a platform it doesn't have), it will attempt to provide a contact with someone who can help. I.21. Is there an optimizing compiler for Icon? Yes. The original implementation was an interpreter. An optimizing compiler was added a few years ago. The interpreter and compiler are largely source-language compatible. The interpreter is used by most Icon programmers because it gets into execution quickly and runs fast enough for most applications. The compiler is best suited for applications that require the fastest possible execution time. In this case, it's generally best to develop the program using the interpreter and then compile the final result for production use. I.22. What do I need to run the interpreter? The Icon interpreter will run on most computers. It requires a reasonable amount of memory, however. Under MS-DOS, the Icon interpreter needs 500KB of application RAM to work well. I.23. What do I need to run the compiler? The Icon compiler is another matter. It requires a C compiler, a fast CPU for tolerable compilation times, a considerable amount of disk space, and a lot of memory -- at least several megabytes. The Icon compiler generates C code, which must then be compiled to produce an executable program. The flexibility that Icon provides to programmers makes compilation technically difficult and the process requires a large amount of memory. The C code it produces is voluminous and stresses the most robust C compilers. Generally speaking, the Icon compiler is practical for platforms in the workstation class but not for most personal computers. Although the compiler can be built and made to run on 286 platforms running standard MS-DOS, only trivially small programs can be compiled. In principle, the Icon compiler is practical on MS-DOS 386/486 platforms with extended memory, but the limited availability of suitable 32-bit C compilers for this environment has discouraged the use of the Icon compiler on such platforms. I.24. Can I build my own implementation of Icon for a new platform? As mentioned above, Icon is written in C and the source code is available via FTP and the Icon Project. The existing implementations are testament to its portability. (a small amount of assembly-language code is required for a context switch, but this is only needed for an optional feature -- co-expressions -- that can be disabled without affecting most of Icon.) New ports involve platform-specific configuration parameters and, in some cases, platform-specific code. The feasibility of a new port and the amount of work it may take depends on the platform -- its architecture, its C compiler, and its environment. Ports to new UNIX platforms generally are easy, although novel architecture may present problems. Ports to new operating systems generally are more difficult, especially if Icon's graphics facilities are implemented. The Icon Project provides what help it can with new ports. In return, it asks that code related to the port to be returned to the Icon Project for inclusion in future versions of the source code for Icon. This makes the new port available to others as well as to the porter when Icon is updated. From icon-group-sender Thu May 18 15:41:59 1995 Received: by cheltenham.cs.arizona.edu; Thu, 18 May 1995 12:20:58 MST To: icon-group-l@cs.arizona.edu Date: Thu, 18 May 1995 15:41:59 GMT From: goer@quads.uchicago.edu (Richard L. Goerwitz) Message-Id: Organization: The University of Chicago Sender: icon-group-request@cs.arizona.edu Reply-To: goer@midway.uchicago.edu Subject: hilit19 + icon revisited Errors-To: icon-group-errors@cs.arizona.edu Those of you who are using hilit19.el with GNU Emacs 19 may want to try out the following code. What it does is to get string literals right. It also allows you to insert a backslash to avoid problems like pound signs inside of string/cset literals being taken as com- ment delimiters: '!@#$%^&*()' ^ You just insert a backslash, and everything works fine. For Icon, \# and # are equivalent inside a string/cset literal. '!@\#$%^&*()' ^ Has anyone, BTW, actually used the new Icon mode I posted some months back? I just couldn't handle all comments being jammed against the margin, the way the standard Emacs Icon mode has them. ;; hilit19.el (Release 2.19) -- customizable highlighting for Emacs19. ;; Copyright (c) 1993 Free Software Foundation, Inc. ;; Hacked by Richard Goerwitz, 18 May 1995 ;; ;; Author: Jonathan Stigelman ;; Keywords: faces ;; ;; This program is free software; you can redistribute it and/or modify ;; it under the terms of the GNU General Public License as published by ;; the Free Software Foundation; either version 2 of the License, or ;; (at your option) any later version. ;; ;; This program is distributed in the hope that it will be useful, ;; but WITHOUT ANY WARRANTY; without even the implied warranty of ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ;; GNU General Public License for more details. ;; ;; You should have received a copy of the GNU General Public License ;; along with this program; if not, write to the Free Software ;; Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. ;; ;;; Commentary: ;; Hilit19.el is a customizable highlighting package for Emacs19. It supports ;; not only source code highlighting, but also Info, RMAIL, VM, gnus... ;; Hilit19 knows (or thinks it knows) how to highlight emacs buffers in ;; about 25 different modes. ;; ;; WHERE TO GET THE LATEST VERSIONS OF HILIT19.EL (beta and release), ;; PLUS LOTS OF OTHER *WAY COOL* STUFF VIA ANONYMOUS FTP: ;; ;; netcom.com:/pub/stig/src/{Beta,Release}/hilit19.el.gz ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; ;; TO SUBMIT BUG REPORTS (or feedback of any sort)... ;; ;; M-x hilit-submit-feedback RET ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; ;; hilit19.el,v 2.19 1993/09/08 18:44:10 stig Release ;; ;; LCD Archive Entry: ;; hilit19|Jonathan Stigelman|Stig@netcom.com| ;; Comprehensive (and comparatively fast) regex-based highlighting for Emacs 19| ;; 1993/09/08 18:44:10|Release 2.19|~/packages/hilit19.el.Z| ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; ;; GENERAL OVERVIEW ;; ;; This package installs numerous hooks to colorfully highlight your ;; source code buffers as well as mail and news buffers. Most ;; programming languages have predefined highlighting patterns. ;; Just load hilit19 and files will be automatically highlighted as ;; they're loaded. ;; ;; Rehighlight a buffer by typing C-S-l (control-shift-lowercase-L). ;; ;; If, when you edit the buffer, the coloring gets messed up, just ;; redraw and the coloring will be adjusted. If automatic highlighting ;; in the current buffer has been turned off, then typing C-u C-S-l will ;; force a rehighlight of the entire buffer. ;; ;; Hilit19 can build faces by examining the names that you give to them ;; For example, green/black-bold-italic-underline would be created as ;; a face with a green foreground, and a black background, using a ;; bold-italic font...with underlining for good measure. ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; ;; SETUP -- In your .emacs: ;; ;; ;; (cond (window-system ;; (setq hilit-mode-enable-list '(not text-mode) ;; hilit-background-mode 'light ;; hilit-inhibit-hooks nil ;; hilit-inhibit-rebinding nil) ;; ;; (require 'hilit19) ;; )) ;; ;; If you like font-lock-mode and want to use both packages, then you can ;; disable hilit for the modes in which you want to use font-lock by listing ;; said modes in hilit-mode-enable-list. ;; ;; (hilit-translate type 'RoyalBlue ; enable highlighting in C/C++ ;; string nil) ; disable string highlighting ;; ;; To get 100% of the utility of hilit19, you may also have to apply the ;; patches below for info.el and vm5.33L_19/vm-summary.el ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; ;; SETUP -- Are you using the right font for Emacs? ;; ;; Emacs cannot properly find bold and italic fonts unless you specify a ;; verbose X11 font name. If you specify a font for emacs in your ;; .Xdefaults, it *MUST* be specified using the long form of the font name. ;; Here's a good font menu: ;; ;; (setq ;; x-fixed-font-alist ;; '("Font Menu" ;; ("Misc" ;; ("6x12" "-misc-fixed-medium-r-semicondensed--12-110-75-75-c-60-*-1") ;; ("6x13" "-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-*-1") ;; ("lucida 13" ;; "-b&h-lucidatypewriter-medium-r-normal-sans-0-0-0-0-m-0-*-1") ;; ("7x13" "-misc-fixed-medium-r-normal--13-120-75-75-c-70-*-1") ;; ("7x14" "-misc-fixed-medium-r-normal--14-130-75-75-c-70-*-1") ;; ("9x15" "-misc-fixed-medium-r-normal--15-140-*-*-c-*-*-1") ;; ("") ;; ("clean 8x8" "-schumacher-clean-medium-r-normal--*-80-*-*-c-*-*-1") ;; ("clean 8x14" "-schumacher-clean-medium-r-normal--*-140-*-*-c-*-*-1") ;; ("clean 8x10" "-schumacher-clean-medium-r-normal--*-100-*-*-c-*-*-1") ;; ("clean 8x16" "-schumacher-clean-medium-r-normal--*-160-*-*-c-*-*-1") ;; ("") ;; ("sony 8x16" "-sony-fixed-medium-r-normal--16-120-100-100-c-80-*-1") ;; ("") ;; ("-- Courier --") ;; ("Courier 10" "-adobe-courier-medium-r-normal--*-100-*-*-m-*-*-1") ;; ("Courier 12" "-adobe-courier-medium-r-normal--*-120-*-*-m-*-*-1") ;; ("Courier 14" "-adobe-courier-medium-r-normal--*-140-*-*-m-*-*-1") ;; ("Courier 18" "-adobe-courier-medium-r-normal--*-180-*-*-m-*-*-1") ;; ("Courier 18-b" "-adobe-courier-bold-r-normal--*-180-*-*-m-*-*-1") ;; ))) ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; ;; KNOWN BUGS/TO DO LIST/HELP WANTED/APPLY WITHIN ;; ;; * When more than one size of font is used in different frames, only one ;; font size can have bold & italic properties. ;; ;; * unbalanced, unescaped double quote characters can confuse hilit19. ;; This will be fixed someday, so don't bug me about it. ;; ;; * ALTHOUGH HILIT19 IS FASTER THAN FONT-LOCK-MODE... ;; For various reasons, the speed of the package could still stand to be ;; improved. If you care to do a little profiling and make things tighter... ;; ;; * hilit-toggle-highlight is flaky when auto-rehighlight is neither t nor nil. ;; Does anyone actually USE this? I think I might just remove it. ;; ;; PROJECTS THAT YOU CAN TAKE OVER BECAUSE I DON'T MUCH CARE ABOUT THEM... ;; ;; * Moved hilit-wysiwyg-replace here from my version of man.el, this is not ;; a bug. The bug is that I don't have a reverse operation yet...just a ;; stub Wysiwyg-anything really belongs in a package of it's own. ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; ;; Thanks to the following people for their input: ;; ebert@enpc.enpc.fr (Rolf EBERT), ada, LaTeX & bibtex highlights ;; Vivek Khera , gnus hooks + random advice & patches ;; brian@athe.WUstl.EDU (Brian Dunford-Shore), prolog highlights ;; John Ladwig , 1st pass nroff highlights ;; campo@sunthpi3.difi.unipi.it (Massimo Campostrini), fortran highlights ;; jayb@laplace.MATH.ColoState.EDU (Jay Bourland), 1st pass dired ;; Yoshio Turner , modula 2 highlights ;; Fritz Knabe , advice & patches ;; Alon Albert , advice & patches ;; dana@thumper.bellcore.com (Dana A. Chee), working on the multi-frame bug ;; derway@ndc.com (Don Erway), for breaking it... ;; moss_r@summer.chem.su.oz.au (Richard Moss), first pass at add-pattern ;; Olivier Lecarme , Pascal & Icon patterns ;; ;; With suggestions and minor regex patches from numerous others... ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; ;; hilit19.el,v ;; Revision 2.19 1993/09/08 18:44:10 stig ;; installed patch for elusive bug in hilit-rehighlight-region that caused ;; hilit-unhighlight-region to hang in an infinite loop. ;; ;; Revision 2.18 1993/08/27 03:51:00 stig ;; minor mods to lisp-mode and c/c++ mode patterns ;; ;; Revision 2.17 1993/08/25 02:19:17 stig ;; work-around for bug in next-overlay-change that caused dired and jargon-mode ;; to hang in an endless loop. Perhaps other modes were doing this too. ;; ;; Revision 2.16 1993/08/22 19:46:00 stig ;; bug fix for next-overlay-change and accompanying change to ;; hilit-unhighlight-region ;; ;; Revision 2.15 1993/08/20 12:16:22 stig ;; minor change to fortran patterns ;; ;; Revision 2.14 1993/08/17 14:12:10 stig ;; added default face mapping for 'formula' which is needed for new latex ;; patterns. ;; ;; twiddled the calendar-mode patterns a bit. ;; ;; Revision 2.13 1993/08/16 04:33:54 stig ;; hilit-set-mode-patterns was screwing up two part patterns. it doesn't now. ;; ;; Revision 2.12 1993/08/16 00:16:41 stig ;; changed references to default-bold-italic to just bold-italic because the ;; font for that face is maintained by emacs. ;; ;; the pattern matcher now starts it's searches from the end of the most ;; recently highlighted region (which is not necessarily the end of the most ;; recently matched regex). ;; ;; multiple errors in pattern matcher now just give an error instead of lots of ;; annoying messages and dings. ;; ;; no longer use vm-summary-mode-hooks. ;; ;; some code moved from hilit-highlight-region to hilit-set-mode-patterns. ;; This will affect you if you pass your patterns directly to ;; hilit-highlight-region....use a pseudo-mode instead. ;; ;; pattern changes to C/C++, latex, texinfo, fortran, nroff, etc. ;; ;; Revision 2.11 1993/08/13 12:12:37 stig ;; removed some crufty commented-out code ;; ;; diverged lisp-mode and emacs-lisp-mode...also added lisp keywords. ;; ;; Revision 2.10 1993/08/13 09:47:06 stig ;; added calendar-mode, icon-mode and pascal-mode patterns ;; ;; commented out hilit-toggle-highlight because I want to phase it out entirely ;; ;; Revision 2.9 1993/08/13 08:44:22 stig ;; added optional case-fold argument to hilit-set-mode-patterns, this case-fold ;; parameter is now stored in hilit-patterns-alist. ;; ;; Revision 2.8 1993/08/12 22:05:03 stig ;; fixed some typos in documentation ;; ;; twiddled some of the color defaults for dark backgrounds ;; ;; always get 'mono color defaults if (not (x-display-color-p)) ;; ;; added hilit-rehighlight-buffer-quietly to dired-after-readin-hook ;; ;; fixed bug in hilit-string-find that mishandled strings of the form: "\\" ;; ;; NEW FUNCTION: hilit-add-mode-pattern... kinda like add-hook for patterns ;; ;; fixed minor pattern bugs for latex-mode and emacs-lisp-mode ;; ;; Revision 2.7 1993/07/30 02:43:01 stig ;; added const to the list of modifiers for C/C++ types ;; ;; Revision 2.6 1993/07/30 00:30:54 stig ;; now permit selection of arbitrary subexpressions for highlighting... ;; fixed keyword patterns for C/C++ using this technique. ;; ;; Revision 2.5 1993/07/28 05:02:56 stig ;; improvements to makefile regular expressions ;; removed about 130 lines just by compacting the big defconst for ;; hilit-face-translation-table into a mapcar and defining a separate table ;; of default faces. ;; ;; Revision 2.4 1993/07/27 14:09:05 stig ;; documented another "known problem" to "head off gripe mail at the pass." ;; ;; Revision 2.3 1993/07/27 02:15:49 stig ;; (hilit-lookup-face-create) incorporated patch which improves it's behavior ;; with more than one frame... Still can't have bold on the same face in two ;; differrent fonts sizes at the same time... ;; ;; Revision 2.2 1993/07/27 02:02:59 stig ;; vastly improved the makefile patterns ;; added hook for mh-show-mode ;; ;; Revision 2.1 1993/07/24 17:46:21 stig ;; Phasing out Info-select-hook... Version 19.18 will use Info-selection-hook. ;; ;; Revision 2.0 1993/07/24 13:50:10 stig ;; better documentation and added the function hilit-submit-feedback. ;; C-S-l (control shift l) repaints the buffer. Other bindings are optional. ;; multi-line highlights no longer cause problems when ;; hilit-auto-rehighlight is 'visible ;; added hilit-predefined-face-list... ;; changed name of hilit-mode-alist to hilit-patterns-alist ;; added hilit-message-quietly to mail-setup-hook ;; added hilit-parser-alist which can be used to apply different patterns to ;; different parts of a buffer. This could be integrated in a far more ;; elegant manner, but it presently serves the purpose of not applying ;; message header patterns to message bodies in mail-mode and it's kin. ;; hilit-set-mode-patterns now takes a list of modes and an optional parse-fn ;; ;;;;;; AND THIS CAN BE APPLIED TO VM 5.33L_19 ;; ;; *** ../site/vm5.33L_19/vm-summary.el Fri Jun 4 22:17:11 1993 ;; --- ./vm-summary.el Tue Jun 22 16:39:30 1993 ;; *************** ;; *** 152,158 **** ;; (insert "->") ;; (delete-char 2) ;; (forward-char -2) ;; ! (and w vm-auto-center-summary (vm-auto-center-summary)))) ;; (and old-window (select-window old-window))))))) ;; ;; (defun vm-mark-for-display-update (message) ;; --- 152,159 ---- ;; (insert "->") ;; (delete-char 2) ;; (forward-char -2) ;; ! (and w vm-auto-center-summary (vm-auto-center-summary)) ;; ! (run-hooks 'vm-summary-pointer-hook))) ;; (and old-window (select-window old-window))))))) ;; ;; (defun vm-mark-for-display-update (message) ;; ;;;;;; ;;; Code: ;; User Options: (defvar hilit-quietly nil "* If non-nil, this inhibits progress indicators during highlighting") (defvar hilit-auto-highlight t "* T if we should highlight all buffers as we find 'em, nil to disable automatic highlighting by the find-file hook.") (defvar hilit-auto-highlight-maxout 60000 ; hilit19 keeps getting bigger... "* auto-highlight is disabled in buffers larger than this") (defvar hilit-auto-rehighlight t "* If this is non-nil, then hilit-redraw and hilit-recenter will also rehighlight part or all of the current buffer. T will rehighlight the whole buffer, a NUMBER will rehighlight that many lines before and after the cursor, and the symbol 'visible' will rehighlight only the visible portion of the current buffer. This variable is buffer-local.") (make-variable-buffer-local 'hilit-auto-rehighlight) (defvar hilit-auto-rehighlight-fallback '(20000 . 100) "* Cons of the form (THRESHOLD . FALLBACK), where FALLBACK is assigned to hilit-auto-rehighlight if the size of a newly opened buffer is larger than THRESHOLD.") (defvar hilit-face-check t "* T slows down highlighting but permits the user to change fonts without losing bold and italic faces... T causes hilit-lookup-face-create to dig through the frame parameters for the current window every time it's called. If you never change fonts in emacs, set this to NIL.") ;; Variables which must be set before loading hilit19. (defvar hilit-inhibit-rebinding nil "If non-nil, this inhibits replacement of recenter, yank, and yank-pop.") (defvar hilit-inhibit-hooks nil "If non-nil, this inhibits installation of hooks for Info, gnus, & vm.") (defvar hilit-background-mode 'light "'mono inhibits color, 'dark or 'light indicate the background brightness.") (defvar hilit-mode-enable-list nil "If a list of modes to exclusively enable or specifically disable. The sense of the list is negated if it begins with the symbol 'not'. Set this variable before you load hilit19. Ex: (perl-mode jargon-mode c-mode) ; just perl, C, and jargon modes (not text-mode) ; all modes except text mode") ;; Variables that are not generally modified directly (defvar hilit-parser-alist nil "alist of major-mode values and parsers called by hilit-rehighlight-buffer. Parsers for a given mode are IGNORED for partial rehighlights...maybe you'd like to make this more universal?") (defvar hilit-patterns-alist nil "alist of major-mode values and default highlighting patterns A highlighting pattern is a list of the form (start end face), where start is a regex, end is either a regex or a match number for start, and face is the name of an entry in hilit-face-translation-table, the name of a face, or nil (which disables the pattern). Each entry in the alist is of the form: (mode . (case-fold pattern [pattern ...])) See the hilit-lookup-face-create documentation for valid face names.") (defvar hilit-predefined-face-list (face-list) "List of faces with which hilit-lookup-face-create will NOT tamper. If hilit19 is dumped into emacs at your site, you may have to set this in your init file.") (eval-when-compile (setq byte-optimize t)) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; Use this to report bugs: (eval-when-compile (require 'reporter)) ; no compilation gripes (defun hilit-submit-feedback () "Submit feedback on hilit19 to the author: Stig@netcom.com" (interactive) (require 'reporter) (and (y-or-n-p "Do you really want to submit a report on hilit19? ") (reporter-submit-bug-report "Jonathan Stigelman " "hilit19.el (Release 2.19)" (and (y-or-n-p "Do you need to include a dump hilit variables? ") (append '( hilit-quietly hilit-inhibit-hooks hilit-background-mode hilit-mode-enable-list hilit-auto-highlight hilit-auto-highlight-maxout hilit-auto-rehighlight hilit-auto-rehighlight-fallback hilit-face-check ) (and (y-or-n-p "Have you modified the standard patterns? ") (yes-or-no-p "Are your patterns *REALLY* relevant? ") '(hilit-parser-alist hilit-patterns-alist hilit-predefined-face-list )))) (function (lambda () (and (y-or-n-p "Is this a problem with font display? ") (insert "\nFrame Configuration:\n====================\n" (prin1-to-string (frame-configuration-to-register ?F)) "\n" )))) nil (concat "This is (check all that apply, and delete what's irrelevant):\n" " [ ] a _MASSIVE_THANK_YOU_ for writing hilit19.el\n" " [ ] An invitation to attend the next Hackers Conference\n" " [ ] You're a RIGHTEOUS HACKER, what are your rates?\n" " [ ] I've used the force and read the source, but I'M CONFUSED\n" " [ ] a PATCH. (output of 'diff -uw old.el new.el' or 'diff -cw')\n" " [ ] a SERIOUS AND REPRODUCABLE BUG that is not an EMACS bug\n" " - I *swear* that it's not already mentioned in the KNOWN BUGS\n" " - I HAVE CHECKED netcom.com:/pub/stig/src/Beta/hilit19.el.gz\n" " for a newer release that fixes the problem.\n" " >> I HAVE ALSO CHECKED netcom.com:/pub/stig/src/Beta/hl319.el.gz\n" " This is the alpha version...what will become hilit19 (Beta 3.0).\n" "\n" "Hey Stig, I *know* you're busy but...\n")))) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; ;; These faces are either a valid face name, or nil ;; if you want to change them, you must do so AFTER hilit19 is loaded (defconst hilit-default-face-table '( ;; used for C/C++, elisp, perl, and Icon (comment firebrick-italic moccasin italic) (include purple Plum1 bold-italic) (define ForestGreen-bold green bold) (defun blue-bold cyan-bold bold-italic) (decl RoyalBlue cyan bold) (type nil yellow nil) (keyword RoyalBlue cyan bold-italic) (label red-underline orange-underlined underline) (string grey40 orange underline) ;; used for Icon (charset grey50 orange underline) ;; some further faces for Ada (struct black-bold white-bold bold) (glob-struct magenta Plum1 default-bold-underline) (named-param DarkGoldenrod Goldenrod underline) ;; and anotherone for LaTeX (crossref DarkGoldenrod Goldenrod underline) (formula Goldenrod DarkGoldenrod underline) ;; compilation buffers (active-error default/pink-bold default/DeepPink-bold default-underline) (error red-bold yellow bold) (warning blue-italic green italic) ;; Makefiles (some faces borrowed from C/C++ too) (rule blue-bold-underline cyan-underline default-bold-underline) ;; VM, GNUS and Text mode (msg-subject blue-bold yellow bold) (msg-from purple-bold green bold) (msg-header firebrick-bold cyan italic) (msg-separator black/tan-bold black/lightblue nil) (msg-quote ForestGreen pink italic) (summary-seen grey40 white nil) (summary-killed grey50 white nil) (summary-Xed OliveDrab2 green nil) (summary-deleted firebrick white italic) (summary-unread RoyalBlue yellow bold) (summary-new blue-bold yellow-bold bold-italic) (summary-current default/skyblue-bold green/dimgrey-bold reverse-default) (gnus-group-unsubscribed grey50 white nil) (gnus-group-empty nil nil nil) (gnus-group-full ForestGreen green italic) (gnus-group-overflowing firebrick red bold-italic) ;; dired mode (dired-directory blue-bold cyan bold) (dired-link firebrick-italic green italic) (dired-ignored ForestGreen moccasin nil) (dired-deleted red-bold-italic orange bold-italic) (dired-marked purple Plum1 nil) ;; Info-mode, and jargon-mode.el and prep.ai.mit.edu:/pub/gnu/jargon* (jargon-entry blue-bold cyan bold) (jargon-xref purple-bold Plum1 italic) (jargon-keyword firebrick-underline yellow underline) ) "alist of default faces (face . (light-default dark-default mono-default)) There is no way for the user to modify this table such that it will have any effect upon the translations used by hilit19. Instead, use the function hilit-translate AFTER hilit19 has been loaded. See also the documentation for hilit-lookup-face-create.") (defconst hilit-face-translation-table (let ((index (or (and (x-display-color-p) (cdr (assq hilit-background-mode '((light . 1) (dark . 2))))) 3))) (mapcar (function (lambda (x) (cons (car x) (nth index x)))) hilit-default-face-table)) "alist that maps symbolic face-names to real face names") ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; To translate one face to another... ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; (defmacro hilit-translate (&rest args) "(hilit-translate FROM TO FROM TO ...): translate each face FROM to the value of its TO face. This is like setq for faces. The function hilit-lookup-face-create will repeatedly translate until no more translations for the face exist in the translation table. See the documentation for hilit-lookup-face-create for names of valid faces." (or (zerop (% (length args) 2)) (error "wrong number of args")) (let (cmdl from to) (while args (setq from (car args) to (nth 1 args) args (nthcdr 2 args) cmdl (cons (list 'hilit-associate ''hilit-face-translation-table (list 'quote from) to) cmdl))) (cons 'progn cmdl))) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; This function actually translates and then creates the faces... ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; (defun hilit-lookup-face-create (face &optional force) "Get a FACE, or create it if it doesn't exist. In order for it to properly create the face, the followwing naming convention must be used: [reverse-](fgcolor[/bgcolor])[-bold][-italic][-underline] Example: (hilit-lookup-face-create 'comment-face) might create and return 'red Each color is either the name of an X color (see .../X11/lib/X11/rgb.txt), a hexadecimal specification of the form \"hex-[0-9A-Fa-f]+\", or \"default\". An optional argument, FORCE, will cause the face to be recopied from the default...which is probably of use only if you've changed fonts. See the documentation for hilit-translate and hilit-face-translation-table." ;; translate the face ... (let ((trec t) visited) (while trec (cond ((memq face visited) (error "face translation loop: %S" visited)) (t (setq visited (cons face visited) trec (assq face hilit-face-translation-table)) (and trec (setq face (cdr trec))))))) ;; make the face if we need to... (let* ((fn (symbol-name face)) (frame (selected-frame)) (basefont (cdr (assq 'font (frame-parameters frame)))) error fgcolor bgcolor) (cond ((or (null face) (memq face hilit-predefined-face-list)) ;; do nothing if the face is nil or if it's predefined. ) ((or force (not (memq face (face-list))) (and hilit-face-check (not (string= (get face 'basefont) basefont)))) (copy-face 'default 'scratch-face) (if (string-match "^reverse-?" fn) (progn (invert-face 'scratch-face) (setq fn (substring fn (match-end 0))))) ;; parse foreground color (if (string-match "^\\(hex-\\)?\\([A-Za-z0-9]+\\)" fn) (setq fgcolor (concat (if (match-beginning 1) "#") (substring fn (match-beginning 2) (match-end 2))) fn (substring fn (match-end 0))) (error "bad face name %S" face)) ;; parse background color (if (string-match "^/\\(hex-\\)?\\([A-Za-z0-9]+\\)" fn) (setq bgcolor (concat (and (match-beginning 1) "#") (substring fn (match-beginning 2) (match-end 2))) fn (substring fn (match-end 0)))) (and (string= "default" fgcolor) (setq fgcolor nil)) (and (string= "default" bgcolor) (setq bgcolor nil)) ;; catch errors if we can't allocate the color(s) (condition-case nil (progn (set-face-foreground 'scratch-face fgcolor) (set-face-background 'scratch-face bgcolor) (copy-face 'scratch-face face) (put face 'basefont basefont)) (error (message "couldn't allocate color for '%s'" (symbol-name face)) (setq face 'default) (setq error t))) (or error ;; don't bother w/ bold or italic if we didn't get the color ;; we wanted, but ignore errors making the face bold or italic ;; if the font isn't available, there's nothing to do about it... (progn (set-face-font face nil frame) (set-face-underline-p face (string-match "underline" fn)) (if (string-match ".*bold" fn) (progn ;; first, fix up this frame's face (make-face-bold face frame 'noerr) ;; now, fix up the face from the global list (set-face-font face (face-font face frame) t))) (if (string-match ".*italic" fn) (progn ;; first, fix up this frame's face (make-face-italic face frame 'noerr) ;; now, fix up the face from the global list (set-face-font face (face-font face frame) t))) )) ))) face) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; Region Highlight/Unhighlight code (Both overlay and text-property versions) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; (defsubst hilit-region-set-face (start end face-name &optional prio prop) "Highlight region from START to END using FACE and, optionally, PRIO. The optional 5th arg, PROP is a property to set instead of 'hilit." (let ((overlay (make-overlay start end))) (overlay-put overlay 'face face-name) (overlay-put overlay (or prop 'hilit) t) (and prio (overlay-put overlay 'priority prio)))) (defun hilit-unhighlight-region (start end &optional quietly) "Unhighlights the region from START to END, optionally in a QUIET way" (interactive "r") (or quietly hilit-quietly (message "Unhighlighting")) (let ((lstart 0)) (while (and start (> start lstart) (< start end)) (mapcar (function (lambda (ovr) (and (overlay-get ovr 'hilit) (delete-overlay ovr)))) (overlays-at start)) (setq lstart start start (next-overlay-change start)))) (or quietly hilit-quietly (message "Done unhighlighting"))) ;;;; These functions use text properties instead of overlays. Text properties ;;;; are copied through kill and yank...which might be convenient, but is not ;;;; terribly efficient as of 19.12, ERGO it's been disabled ;; ;;(defsubst hilit-region-set-face (start end face-name &optional prio prop) ;; "Highlight region from START to END using FACE and, optionally, PRIO. ;;The optional 5th arg, PROP is a property to set instead of 'hilit." ;; (put-text-property start end 'face face-name) ;; ) ;; ;;(defun hilit-unhighlight-region (start end &optional quietly) ;; "Unhighlights the region from START to END, optionally in a QUIET way" ;; (interactive "r") ;; (let ((buffer-read-only nil) ;; (bm (buffer-modified-p))) ;; (remove-text-properties start end '(face)) ;; (set-buffer-modified-p bm))) ;;;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; Pattern Application code and user functions ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; (defun hilit-highlight-region (start end &optional patterns quietly) "Highlights the area of the buffer between START and END (the region when interactive). Without the optional PATTERNS argument, the pattern for major-mode is used. If PATTERNS is a symbol, then the patterns associated with that symbol are used. QUIETLY suppresses progress messages if non-nil." (interactive "r") (cond ((null patterns) (setq patterns (cdr (assq major-mode hilit-patterns-alist)))) ((symbolp patterns) (setq patterns (cdr (assq patterns hilit-patterns-alist))))) ;; txt prop: (setq patterns (reverse patterns)) (let ((case-fold-search (car patterns)) (prio (1- (length patterns))) ;; txt prop: (buffer-read-only nil) ;; txt prop: (bm (buffer-modified-p)) p pstart pend face mstart (puke-count 0)) ;; txt prop: (unwind-protect (setq patterns (cdr patterns)) ; remove case-fold from head of pattern (save-excursion (save-restriction (narrow-to-region start end) (while patterns (setq p (car patterns)) (setq pstart (car p) pend (nth 1 p) face (hilit-lookup-face-create (nth 2 p))) (if (not face) ; skipped if nil nil (or quietly hilit-quietly (message "highlighting %d: %s%s" prio pstart (if (stringp pend) (concat " ... " pend) ""))) (goto-char (point-min)) (condition-case msg (cond ((symbolp pstart) ;; inner loop -- special function to find pattern (let (region) (while (setq region (funcall pstart pend)) (hilit-region-set-face (car region) (cdr region) face prio)))) ((stringp pend) ;; inner loop -- regex-start ... regex-end (while (re-search-forward pstart nil t nil) (goto-char (setq mstart (match-beginning 0))) (if (re-search-forward pend nil t nil) (hilit-region-set-face mstart (match-end 0) face prio) (forward-char 1)))) ((numberp pend) ;; inner loop -- just one regex to match whole pattern (while (re-search-forward pstart nil t nil) (goto-char (match-end pend)) (hilit-region-set-face (match-beginning pend) (match-end pend) face prio))) (t (error "malformed pattern"))) (error (if (> (setq puke-count (1+ puke-count)) 1) (error msg) (message "Error: '%s'" msg) (ding) (sit-for 4))))) (setq prio (1- prio) patterns (cdr patterns))) )) (or quietly hilit-quietly (message "")) ; "Done highlighting" ;; txt prop: (set-buffer-modified-p bm)) ; unwind protection )) (defun hilit-rehighlight-region (start end &optional quietly) "Re-highlights the region, optionally in a QUIET way" (interactive "r") (save-restriction (widen) (setq start (apply 'min start (mapcar 'overlay-start (overlays-at start))) end (apply 'max end (mapcar 'overlay-end (overlays-at end)))) (hilit-unhighlight-region start end quietly) (hilit-highlight-region start end nil quietly))) (defun hilit-rehighlight-buffer (&optional quietly) "Re-highlights the buffer, optionally in a QUIET way" (interactive "") (let ((parse-fn (cdr (assq major-mode hilit-parser-alist)))) (if parse-fn (funcall parse-fn quietly) (hilit-rehighlight-region (point-min) (point-max) quietly))) nil) (defun hilit-rehighlight-buffer-quietly () (hilit-rehighlight-buffer t)) (defun hilit-rehighlight-message (quietly) "Highlight a buffer containing a news article or mail message." (save-excursion (goto-char (point-min)) (re-search-forward "^$" nil 'noerr) (hilit-unhighlight-region (point-min) (point-max) quietly) (hilit-highlight-region (point-min) (point) 'msg-header quietly) (hilit-highlight-region (point) (point-max) 'msg-body quietly))) (defalias 'hilit-highlight-buffer 'hilit-rehighlight-buffer) ;; Well, I want to remove this function...there's one sure way to find out if ;; anyone uses it or not...and that's to comment it out. ;; ;; (defun hilit-toggle-highlight (arg) ;; "Locally toggle highlighting. With arg, forces highlighting off." ;; (interactive "P") ;; ;; FIXME -- this loses numeric information in hilit-auto-rehighlight ;; (setq hilit-auto-rehighlight ;; (and (not arg) (not hilit-auto-rehighlight))) ;; (if hilit-auto-rehighlight ;; (hilit-rehighlight-buffer) ;; (hilit-unhighlight-region (point-min) (point-max))) ;; (message "Rehighlighting is set to %s" hilit-auto-rehighlight)) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; HOOKS ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; (defun hilit-find-file-hook () "Find-file hook for hilit package. See the variable hilit-auto-highlight." (cond ((and hilit-auto-highlight (assq major-mode hilit-patterns-alist)) (if (> buffer-saved-size (car hilit-auto-rehighlight-fallback)) (setq hilit-auto-rehighlight (cdr hilit-auto-rehighlight-fallback))) (if (> buffer-saved-size hilit-auto-highlight-maxout) nil (hilit-rehighlight-buffer) (set-buffer-modified-p nil))))) (defun hilit-repaint-command (arg) "Rehighlights according to the value of hilit-auto-rehighlight, or the prefix argument if that is specified. \t\\[hilit-repaint-command]\t\trepaint according to hilit-auto-rehighlight \t^U \\[hilit-repaint-command]\trepaint entire buffer \t^U - \\[hilit-repaint-command]\trepaint visible portion of buffer \t^U n \\[hilit-repaint-command]\trepaint n lines to either side of point" (interactive "P") (let (st en quietly) (or arg (setq arg hilit-auto-rehighlight)) (cond ((or (eq arg 'visible) (eq arg '-)) (setq st (window-start) en (window-end) quietly t)) ((numberp arg) (setq st (save-excursion (forward-line (- arg)) (point)) en (save-excursion (forward-line arg) (point)))) (arg (hilit-rehighlight-buffer))) (if st (hilit-rehighlight-region st en quietly)))) (defun hilit-recenter (arg) "Recenter, then rehighlight according to hilit-auto-rehighlight. If called with an unspecified prefix argument (^U but no number), then a rehighlight of the entire buffer is forced." (interactive "P") (recenter arg) ;; force display update (sit-for 0) (hilit-repaint-command (consp arg))) (defun hilit-yank (arg) "Yank with rehighlighting" (interactive "*P") (let ((transient-mark-mode nil)) (yank arg) (and hilit-auto-rehighlight (hilit-rehighlight-region (region-beginning) (region-end) t)) (setq this-command 'yank))) (defun hilit-yank-pop (arg) "Yank-pop with rehighlighting" (interactive "*p") (let ((transient-mark-mode nil)) (yank-pop arg) (and hilit-auto-rehighlight (hilit-rehighlight-region (region-beginning) (region-end) t)) (setq this-command 'yank))) ;;; this line highlighting stuff is untested. play with it only if you feel ;;; adventurous...don't ask me to fix it...though you're welcome to. -- Stig ;; ;; (defun hilit-rehighlight-line-quietly (&rest args) ;; "Quietly rehighlight just this line. ;; Useful as an after change hook in VM/gnus summary buffers and dired buffers. ;; If only there were an after-change-function, that is..." ;; (save-excursion ;; (push-mark nil t) ;; (hilit-rehighlight-yank-region) ;; (and orig-achange-function (apply orig-achange-function args)))) ;; ;; (defun hilit-install-line-hooks () ;; (make-variable-buffer-local 'after-change-function) ;; (make-local-variable 'orig-achange-function) ;; (setq orig-achange-function after-change-function) ;; (setq after-change-function 'hilit-rehighlight-line-quietly)) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; Wysiwyg Stuff... take it away and build a whole package around it! ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; ;; ; For the Jargon-impaired, WYSIWYG === What You See Is What You Get ;; ; Sure, it sucks to type. Oh, well. ;; (defun hilit-wysiwyg-replace () ;; "Replace overstruck text with normal text that's been overlayed with the ;; appropriate text attribute. Suitable for a find-file hook." ;; (save-excursion ;; (goto-char (point-min)) ;; (let ((wysb (hilit-lookup-face-create 'wysiwyg-bold)) ;; (wysu (hilit-lookup-face-create 'wysiwyg-underline)) ;; (bmod (buffer-modified-p))) ;; (while (re-search-forward "\\(.\b.\\)+" nil t) ;; (let ((st (match-beginning 0)) (en (match-end 0))) ;; (goto-char st) ;; (if (looking-at "_") ;; (hilit-region-set-face st en wysu 100 'wysiwyg) ;; (hilit-region-set-face st en wysb 100 'wysiwyg)) ;; (while (and (< (point) en) (looking-at ".\b")) ;; (replace-match "") (forward-char)) ;; )) ;; (set-buffer-modified-p bmod)))) ;; ;; ; is this more appropriate as a write-file-hook or a write-contents-hook? ;; (defun hilit-wysiwyg-write-repair () ;; "Replace wysiwyg overlays with overstrike text." ;; (message "*sigh* hilit-wysiwyg-write-repair not implemented yet") ;; ;; For efficiency, this hook should copy the current buffer to a scratch ;; buffer and do it's overstriking there. Overlays are not copied, so it'll ;; be necessary to hop back and forth. This is OK since you're not fiddling ;; with--making or deleting--any overlays. THEN write the new buffer, ;; delete it, and RETURN T. << important ;; ;; Just so you know...there is already an emacs function called ;; underline-region that does underlining. I think that the thing to do is ;; extend that to do overstriking as well. ;; ;; (while (< start end) ;; (mapcar (function (lambda (ovr) ;; (and (overlay-get ovr 'hilit) (delete-overlay ovr)))) ;; (overlays-at start)) ;; (setq start (next-overlay-change start))) ;; nil) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; Initialization. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; (and (not hilit-inhibit-rebinding) window-system (progn (substitute-key-definition 'yank 'hilit-yank (current-global-map)) (substitute-key-definition 'yank-pop 'hilit-yank-pop (current-global-map)) (substitute-key-definition 'recenter 'hilit-recenter (current-global-map)))) (global-set-key [?\C-\S-l] 'hilit-repaint-command) (and window-system (add-hook 'find-file-hooks 'hilit-find-file-hook t)) (eval-when-compile (require 'gnus)) ; no compilation gripes (and (not hilit-inhibit-hooks) window-system (condition-case c (progn ;; BUFFER highlights... (mapcar (function (lambda (hook) (add-hook hook 'hilit-rehighlight-buffer-quietly))) '( Info-selection-hook ;; runs too early vm-summary-mode-hooks vm-summary-pointer-hook vm-preview-message-hook vm-show-message-hook gnus-article-prepare-hook gnus-summary-prepare-hook gnus-group-prepare-hook rmail-show-message-hook mail-setup-hook mh-show-mode-hook dired-after-readin-hook )) ;; rehighlight only visible part of summary buffer for speed. (add-hook 'gnus-mark-article-hook (function (lambda () (or (memq gnus-current-article gnus-newsgroup-marked) (gnus-summary-mark-as-read gnus-current-article)) (gnus-summary-set-current-mark) (save-excursion (set-buffer gnus-summary-buffer) (hilit-rehighlight-region (window-start) (window-end) t) )))) ;; only need prepare article hook ;; ;; (add-hook 'gnus-select-article-hook ;; '(lambda () (save-excursion ;; (set-buffer gnus-article-buffer) ;; (hilit-rehighlight-buffer)))) ) (error (message "Error loading highlight hooks: %s" c) (ding) (sit-for 1)))) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; Default patterns for various modes. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;; do I need this? I changed the defconst to a defvar because defconst is ;;; inappropriate, but I don't know why I wanted hilit-patterns-alist to be ;;; reset on every reload... (setq hilit-patterns-alist nil) (defun hilit-associate (alist key val) "creates, or destructively replaces, the pair (key . val) in alist" (let ((oldentry (assq key (eval alist)))) (if oldentry (setcdr oldentry val) (set alist (cons (cons key val) (eval alist)))))) (defun hilit-set-mode-patterns (modelist patterns &optional parse-fn case-fold) "Sets the default highlighting patterns for MODE to PATTERNS. See the variable hilit-mode-enable-list. Takes optional arguments PARSE-FN and CASE-FOLD." ;; change pattern (mapcar (function (lambda (p) (and (stringp (car p)) (null (nth 1 p)) (setcar (cdr p) 0)))) patterns) (setq patterns (cons case-fold patterns)) (or (consp modelist) (setq modelist (list modelist))) (let (ok (flip (eq (car hilit-mode-enable-list) 'not))) (mapcar (function (lambda (m) (setq ok (or (null hilit-mode-enable-list) (memq m hilit-mode-enable-list))) (and flip (setq ok (not ok))) (and ok (progn (and parse-fn (hilit-associate 'hilit-parser-alist m parse-fn)) (hilit-associate 'hilit-patterns-alist m patterns))))) modelist))) (defun hilit-add-pattern (pstart pend face &optional mode first) "Highlight pstart with face for the current major-mode. Optionally, place the new pattern first in the pattern list" (interactive "sPattern start regex: \nsPattern end regex (default none): \nxFace: ") (and (equal pstart "") (error "Must specify starting regex")) (cond ((equal pend "") (setq pend 0)) ((string-match "^[0-9]+$" pend) (setq pend (string-to-int pend)))) (or mode (setq mode major-mode)) (let ((old-patterns (cdr (assq mode hilit-patterns-alist))) (new-pat (list pstart pend face))) (cond ((not old-patterns) (hilit-set-mode-patterns mode (list new-pat))) (first (setcdr old-patterns (cons new-pat (cdr old-patterns)))) (t (nconc old-patterns (list new-pat))))) (and (interactive-p) (hilit-rehighlight-buffer))) (defun hilit-string-find (qchar) "looks for a string and returns (start . end) or NIL. The argument QCHAR is the character that would precede a character constant double quote. Finds strings delimited by double quotes. The first double quote may not be preceded by QCHAR and the closing double quote may not be preceded by an odd number of backslashes." (let (st en) (while (and (search-forward "\"" nil t) (eq qchar (char-after (1- (setq st (match-beginning 0))))))) (while (and (search-forward "\"" nil t) (save-excursion (setq en (point)) (forward-char -1) (skip-chars-backward "\\\\") (forward-char 1) (not (zerop (% (- en (point)) 2)))))) (and en (cons st en)))) ;; return types on same line... ;; ("^[a-zA-z].*\\(\\w\\|[$_]\\)+\\s *\\(\\(\\w\\|[$_]\\)+\\s *((\\|(\\)[^)]*)+" nil defun) ;; On another note, a working pattern for grabbing function definitions for C is ;; ;; ("^[a-zA-Z_]+.*[;{]$" nil ForestGreen) ; global defns ( start at col 1 ) ;; ("^[a-zA-Z_]+.*(" ")" defun) ;; ; defuns assumed to start at col 1, not with # or { ;; ;; this will make external declarations/definitions green, and function ;; definitions the defun face. Hmmm - seems to work for me anyway. (let ((comments '(("/\\*" "\\*/" comment))) (c++-comments '(("//.*$" nil comment) ("^/.*$" nil comment))) (strings '((hilit-string-find ?' string))) (preprocessor '(("^#[ \t]*\\(undef\\|define\\).*$" "[^\\]$" define) ("^#.*$" nil include)))) (hilit-set-mode-patterns '(c-mode c++-c-mode elec-c-mode) (append comments strings preprocessor '( ;; function decls are expected to have types on the previous line ("^\\(\\w\\|[$_]\\)+\\s *\\(\\(\\w\\|[$_]\\)+\\s *((\\|(\\)[^)]*)+" nil defun) ("^\\(typedef\\|struct\\|union\\|enum\\).*$" nil decl) ;; datatype -- black magic regular expression ("[ \n\t({]\\(\\(const\\|register\\|volatile\\|unsigned\\|extern\\|static\\)\\s +\\)*\\(\\(\\w\\|[$_]\\)+_t\\|float\\|double\\|void\\|char\\|short\\|int\\|long\\|FILE\\|\\(\\(struct\\|union\\|enum\\)\\([ \t]+\\(\\w\\|[$_]\\)*\\)\\)\\)\\(\\s +\\*+)?\\|[ \n\t;()]\\)" nil type) ;; key words ("[^_]\\<\\(return\\|goto\\|if\\|else\\|case\\|default\\|switch\\|break\\|continue\\|while\\|do\\|for\\)\\>[^_]" 1 keyword) ))) (hilit-set-mode-patterns 'c++-mode (append comments c++-comments strings preprocessor '( ;; function decls are expected to have types on the previous line ("^\\(\\(\\w\\|[$_]\\)+::\\)?\\(\\w\\|[$_]\\)+\\s *\\(\\(\\w\\|[$_]\\)+\\s *((\\|(\\)[^)]*)+" nil defun) ("^\\(\\(\\w\\|[$_]\\)+[ \t]*::[ \t]*\\)?\\(\\(\\w\\|[$_]\\)+\\|operator.*\\)\\s *\\(\\(\\w\\|[$_]\\)+\\s *((\\|(\\)[^)]*)+" nil defun) ("^\\(template\\|typedef\\|struct\\|union\\|class\\|enum\\|public\\|private\\|protected\\).*$" nil decl) ;; datatype -- black magic regular expression ("[ \n\t({]\\(\\(const\\|register\\|volatile\\|unsigned\\|extern\\|static\\)\\s +\\)*\\(\\(\\w\\|[$_]\\)+_t\\|float\\|double\\|void\\|char\\|short\\|int\\|long\\|FILE\\|\\(\\(struct\\|union\\|enum\\|class\\)\\([ \t]+\\(\\w\\|[$_]\\)*\\)\\)\\)\\(\\s +\\*+)?\\|[ \n\t;()]\\)" nil type) ;; key words ("[^_]\\<\\(return\\|goto\\|if\\|else\\|case\\|default\\|switch\\|break\\|continue\\|while\\|do\\|for\\|public\\|protected\\|private\\|delete\\|new\\)\\>[^_]" 1 keyword))))) (hilit-set-mode-patterns 'perl-mode '(("\\s #.*$" nil comment) ("^#.*$" nil comment) ("\"[^\\\"]*\\(\\\\\\(.\\|\n\\)[^\\\"]*\\)*\"" nil string) ("^\\(__....?__\\|\\s *\\sw+:\\)" nil label) ("^require.*$" nil include) ("^package.*$" nil decl) ("^\\s *sub\\s +\\(\\w\\|[_']\\)+" nil defun) ("\\b\\(do\\|if\\|unless\\|while\\|until\\|else\\|elsif\\|for\\|foreach\\|continue\\|next\\|redo\\|last\\|goto\\|return\\|die\\|exit\\)\\b" nil keyword))) (hilit-set-mode-patterns 'ada-mode '(;; comments ("--.*$" nil comment) ;; main structure ("[ \t\n]procedure[ \t]" "\\([ \t]\\(is\\|renames\\)\\|);\\)" glob-struct) ("[ \t\n]task[ \t]" "[ \t]is" glob-struct) ("[ \t\n]function[ \t]" "return[ \t]+[A-Za-z_0-9]+[ \t]*\\(is\\|;\\|renames\\)" glob-struct) ("[ \t\n]package[ \t]" "[ \t]\\(is\\|renames\\)" glob-struct) ;; if there is nothing before "private", it is part of the structure ("^[ \t]*private[ \t\n]" nil glob-struct) ;; if there is no indentation before the "end", then it is most ;; probably the end of the package ("^end.*$" ";" glob-struct) ;; program structure -- "null", "delay" and "terminate" omitted ("[ \n\t]\\(in\\|out\\|select\\|if\\|else\\|case\\|when\\|and\\|or\\|not\\|accept\\|loop\\|do\\|then\\|elsif\\|else\\|for\\|while\\|exit\\)[ \n\t;]" nil struct) ;; block structure ("[ \n\t]\\(begin\\|end\\|declare\\|exception\\|generic\\|raise\\|return\\|package\\|body\\)[ \n\t;]" nil struct) ;; type declaration ("^[ \t]*\\(type\\|subtype\\).*$" ";" decl) ("[ \t]+is record.*$" "end record;" decl) ;; "pragma", "with", and "use" are close to C cpp directives ("^[ \t]*\\(with\\|pragma\\|use\\)" ";" include) ;; nice for named parameters, but not so beautiful in case statements ("[A-Za-z_0-9.]+[ \t]*=>" nil named-param) ;; string constants probably not everybody likes this one ("\"" ".*\"" string))) (hilit-set-mode-patterns 'fortran-mode '(("^[*Cc].*$" nil comment) ("'[^'\n]*'" nil string) ("\\(^[ \t]*[0-9]+\\|[ \t]continue[ \t\n]\\|format\\)" nil define) ("[ \t]\\(do\\|do[ \t]*[0-9]+\\|go[ \t]*to[ \t]*[0-9]+\\|end[ \t]*do\\|if\\|else[ \t]*if\\|then\\|else\\|end[ \t]*if\\)[ \t\n(]" nil define) ("[ \t]\\(call\\|program\\|subroutine\\|function\\|stop\\|return\\|end\\|include\\)[ \t\n]" nil include) ("[ \t]\\(parameter[\t\n ]*([^)]*)\\|data\\|save\\|common[ \t\n]*/[^/]*/\\)" nil decl) ("^ ." nil type) ("implicit[ \t]*none" nil decl) ("\\([ \t]\\|implicit[ \t]*\\)\\(dimension\\|integer\\|real\\|double[ \t]*precision\\|character\\|logical\\|complex\\|double[ \t]*complex\\)\\([*][0-9]*\\|[ \t\n]\\)" nil keyword) ) nil 'case-insensitive) (hilit-set-mode-patterns '(m2-mode modula-2-mode) '(("(\\*" "\\*)" comment) (hilit-string-find ?\\ string) ("^[ \t]*PROCEDURE[ \t]+\\w+[^ \t(;]*" nil defun) ("\\<\\(RECORD\\|ARRAY\\|OF\\|POINTER\\|TO\\|BEGIN\\|END\\|FOR\\|IF\\|THEN\\|ELSE\\|ELSIF\\|CASE\\|WHILE\\|DO\\|MODULE\\|FROM\\|RETURN\\|IMPORT\\|EXPORT\\|VAR\\|LOOP\\|UNTIL\\|\\DEFINITION\\|IMPLEMENTATION\\|AND\\|OR\\|NOT\\|CONST\\|TYPE\\|QUALIFIED\\)\\>" nil keyword) ) nil 'case-insensitive) (hilit-set-mode-patterns 'prolog-mode '(("/\\*" "\\*/" comment) ("%.*$" nil comment) (":-" nil defun) ("!" nil label) ("\"[^\\\"]*\\(\\\\\\(.\\|\n\\)[^\\\"]*\\)*\"" nil string) ("\\b\\(is\\|mod\\)\\b" nil keyword) ("\\(->\\|-->\\|;\\|==\\|\\\\==\\|=<\\|>=\\|<\\|>\\|=\\|\\\\=\\|=:=\\|=\\\.\\\.\\|\\\\\\\+\\)" nil decl) ("\\(\\\[\\||\\|\\\]\\)" nil include))) (hilit-set-mode-patterns '( LaTeX-mode japanese-LaTeX-mode SliTeX-mode japanese-SliTeX-mode FoilTeX-mode latex-mode ) '( ;; comments ("[^\\]%.*$" nil comment) ;; the following two match \foo[xx]{xx} or \foo*{xx} or \foo{xx} ("\\\\\\(sub\\)*\\(paragraph\\|section\\)\\(\*\\|\\[.*\\]\\)?{" "}" keyword) ("\\\\\\(chapter\\|part\\)\\(\*\\|\\[.*\\]\\)?{" "}" keyword) ("\\\\footnote\\(mark\\|text\\)?{" "}" keyword) ("\\\\[a-z]+box" nil keyword) ("\\\\\\(v\\|h\\)space\\(\*\\)?{" "}" keyword) ;; (re-)define new commands/environments/counters ("\\\\\\(re\\)?new\\(environment\\|command\\){" "}" defun) ("\\\\new\\(length\\|theorem\\|counter\\){" "}" defun) ;; various declarations/definitions ("\\\\\\(setlength\\|settowidth\\|addtolength\\|setcounter\\|addtocounter\\)" nil define) ("\\\\\\(title\\|author\\|date\\|thanks\\){" "}" define) ("\\\\documentstyle\\(\\[.*\\]\\)?{" "}" decl) ("\\\\\\(begin\\|end\\|nofiles\\|includeonly\\){" "}" decl) ("\\\\\\(raggedright\\|makeindex\\|makeglossary\\|maketitle\\)\\b" nil decl) ("\\\\\\(pagestyle\\|thispagestyle\\|pagenumbering\\){" "}" decl) ("\\\\\\(normalsize\\|small\\|footnotesize\\|scriptsize\\|tiny\\|large\\|Large\\|LARGE\\|huge\\|Huge\\)\\b" nil decl) ("\\\\\\(appendix\\|tableofcontents\\|listoffigures\\|listoftables\\)\\b" nil decl) ("\\\\\\(bf\\|em\\|it\\|rm\\|sf\\|sl\\|ss\\|tt\\)\\b" nil decl) ;; label-like things ("\\\\item\\(\\[[^]]*\\]\\)?" nil label) ("\\\\caption\\(\\[[^]]*\\]\\)?{" "}" label) ;; formulas ("\\\\(" "\\\\)" formula) ; \( \) ("\\\\\\[" "\\\\\\]" formula) ; \[ \] ("[^$]\\($\\($[^$]*\\$\\|[^$]*\\)\\$\\)" 1 formula) ; '$...$' or '$$...$$' ;; things that bring in external files ("\\\\\\(include\\|input\\|bibliography\\){" "}" include) ;; "wysiwyg" emphasis -- these don't work with nested expressions ;; ("{\\\\\\(em\\|it\\|sl\\)" "}" italic) ;; ("{\\\\bf" "}" bold) ("``" "''" string) ;; things that do some sort of cross-reference ("\\\\\\(\\(no\\)?cite\\|\\(page\\)?ref\\|label\\|index\\|glossary\\){" "}" crossref) )) (hilit-set-mode-patterns 'bibtex-mode '(;;(";.*$" nil comment) ("%.*$" nil comment) ("@[a-zA-Z]+" nil keyword) ("{[ \t]*[-a-z:_A-Z0-9]+," nil label) ; is wrong sometimes ("^[ \t]*[a-zA-Z]+[ \t]*=" nil define))) (hilit-set-mode-patterns 'compilation-mode '( ("^[-_.\"A-Za-z0-9]+\\(:\\|, line \\)[0-9]+: warning:.*$" nil warning) ("^[-_.\"A-Za-z0-9]+\\(:\\|, line \\)[0-9]+:.*$" nil error) )) (hilit-set-mode-patterns 'makefile-mode '(("^#.*$" nil comment) ("[^$]#.*$" nil comment) ;; rules ("^[^ \t\n]*%[^ \t\n]*[ \t]*::?[ \t]*[^ \t\n]*[ \t]*\\(#.*\\)?$" nil rule) ("^[.][A-Za-z][A-Za-z]?\..*$" nil rule) ;; variable definition ("^[_A-Za-z0-9]+[ \t]*\+?=" nil define) ("\\( \\|:=\\)[_A-Za-z0-9]+[ \t]*\\+=" nil define) ;; variable references ("\\$\\([^ \t\n{(]\\|[{(]@?[_A-Za-z0-9:.,%/=]+[)}]\\)" nil keyword) ("^[A-Za-z0-9.,/_-]+[ \t]*:.*$" nil defun) ("^include " nil include))) (let* ((header-patterns '(("^Subject:.*$" nil msg-subject) ("^From:.*$" nil msg-from) ("^--text follows this line--$" nil msg-separator) ("^[A-Za-z][A-Za-z0-9-]+:" nil msg-header))) (body-patterns '(("^\\(In article\\|[ \t]*\\w*[]<>}|]\\).*$" nil msg-quote))) (message-patterns (append header-patterns body-patterns))) (hilit-set-mode-patterns 'msg-header header-patterns) (hilit-set-mode-patterns 'msg-body body-patterns) (hilit-set-mode-patterns '(vm-mode text-mode mail-mode rmail-mode gnus-article-mode news-reply-mode mh-show-mode) message-patterns 'hilit-rehighlight-message)) (hilit-set-mode-patterns 'gnus-group-mode '(("^U.*$" nil gnus-group-unsubscribed) ("^ +[01]?[0-9]:.*$" nil gnus-group-empty) ("^ +[2-9][0-9]:.*$" nil gnus-group-full) ("^ +[0-9][0-9][0-9]+:.*$" nil gnus-group-overflowing))) (hilit-set-mode-patterns 'gnus-summary-mode '(("^D +[0-9]+: \\[.*$" nil summary-seen) ("^K +[0-9]+: \\[.*$" nil summary-killed) ("^X +[0-9]+: \\[.*$" nil summary-Xed) ("^- +[0-9]+: \\[.*$" nil summary-unread) ("^. +[0-9]+:\\+\\[.*$" nil summary-current) ("^ +[0-9]+: \\[.*$" nil summary-new) )) (hilit-set-mode-patterns 'vm-summary-mode '(("^ .*$" nil summary-seen) ("^->.*$" nil summary-current) ("^ D.*$" nil summary-deleted) ("^ U.*$" nil summary-unread) ("^ N.*$" nil summary-new))) ;;; this will match only comments w/ an even (zero is even) number of quotes... ;;; which is still inadequate because it matches comments in multi-line strings ;;; how anal do you want to get about never highlighting comments in strings? ;;; I could twiddle with this forever and still it wouldn't be perfect. ;;; (";\\([^\"\n]*\"[^\"\n]*\"\\)*[^\"\n]*$" nil comment) (hilit-set-mode-patterns '(emacs-lisp-mode lisp-interaction-mode) '( (";.*" nil comment) ;;; This almost works...but I think I'll stick with the parser function ;;;("[^?]\\(\"\\(\"\\||\\([^\"]+\\|[\\]\\([\\][\\]\\)*\"\\)*\"\\)\\)" 1 string) (hilit-string-find ?\\ string) ("^\\s *(def\\(un\\|macro\\|advice\\|alias\\|subst\\)[ \t\n]" "\\()\\|nil\\)" defun) ("^\\s *(defvar\\s +\\S +" nil decl) ("^\\s *(defconst\\s +\\S +" nil define) ("^\\s *(\\(provide\\|require\\|\\(auto\\)?load\\).*$" nil include) ("\\s *\\&\\(rest\\|optional\\)\\s *" nil keyword) ("(\\(let\\*?\\|cond\\|if\\|or\\|and\\|map\\(car\\|concat\\)\\|prog[n1*]?\\|while\\|lambda\\|function\\|set\\([qf]\\|car\\|cdr\\)?\\|nconc\\|eval-when-compile\\|condition-case\\|unwind-protect\\|catch\\|throw\\|error\\)[ \t\n]" 1 keyword) )) (hilit-set-mode-patterns '(lisp-mode ilisp-mode) '( (";.*" nil comment) ("#|" "|#" comment) ;;; This almost works...but I think I'll stick with the parser function ;;;("[^?]\\(\"\\(\"\\||\\([^\"]+\\|[\\]\\([\\][\\]\\)*\"\\)*\"\\)\\)" 1 string) (hilit-string-find ?\\ string) ;; this is waaaaaaaay too slow ;; ("^\\s *(def\\(un\\|macro\\|advice\\|alias\\|method\\|subst\\)\\s \\S +[ \t\n]+\\(nil\\|(\\(([^()]*)\\|[^()]+\\)*)\\)" nil defun) ("^\\s *(def\\(un\\|macro\\|advice\\|subst\\|method\\)\\s " "\\()\\|nil\\)" defun) ("^\\s *(\\(def\\(var\\|type\\|parameter\\)\\|declare\\)\\s +\\S +" nil decl) ("^\\s *(def\\(const\\(ant\\)?\\|class\\|struct\\)\\s \\S +[ \t\n]+\\((\\(([^()]*)\\|[^()]+\\)*)\\)?" nil define) ("^\\s *(\\(provide\\|require\\|\\(auto\\)?load\\).*$" nil include) ("[ \t]\\&\\(key\\|rest\\|optional\\|aux\\)\\s *" nil keyword) ("(\\(let\\*?\\|locally\\|cond\\|if\\*?\\|or\\|and\\|map\\(car\\|c[ao]n\\)?\\|prog[nv1*]?\\|while\\|when\\|unless\\|do\\(\\*\\|list\\|times\\)\\|lambda\\|function\\|values\\|set\\([qf]\\|car\\|cdr\\)?\\|rplac[ad]\\|nconc\\|block\\|go\\|return\\(-from\\)?\\|[ec]?\\(type\\)?case\\|multiple-value-\\(bind\\|setq\\|list\\|call\\|prog1\\)\\|unwind-protect\\|handler-case\\|catch\\|throw\\|eval-when\\(-compile\\)?\\)[ \t\n]" 1 keyword) )) (hilit-set-mode-patterns 'plain-tex-mode '(("^%%.*$" nil comment) ("{\\\\em\\([^}]+\\)}" nil comment) ("\\(\\\\\\w+\\)" nil keyword) ("{\\\\bf\\([^}]+\\)}" nil keyword) ("^[ \t\n]*\\\\def[\\\\@]\\(\\w+\\)" nil defun) ("\\\\\\(begin\\|end\\){\\([A-Za-z0-9\\*]+\\)}" nil defun) ;; ("[^\\\\]\\$\\([^$]*\\)\\$" nil string) ("\\$\\([^$]*\\)\\$" nil string) )) ;; Reasonable extensions would include smarter parameter handling for such ;; things as the .IX and .I macros, which alternate the handling of following ;; arguments. (hilit-set-mode-patterns 'nroff-mode '(("^\\.[\\\][\\\"].*$" nil comment) ("^\\.so .*$" nil include) ("^\\.[ST]H.*$" nil defun) ;; ("^[^\\.].*\"[^\\\"]*\\(\\\\\\(.\\)[^\\\"]*\\)*\"" nil string) ("\"" "[^\\]\"" string) ("^\\.[A-Z12\\\\].*$" nil define) ("\\([\\\][^ ]*\\)" nil keyword) ("^\\.[A-Z].*$" nil keyword)) nil 'case-insensitive) (hilit-set-mode-patterns 'texinfo-mode '(("^\\(@c\\|@comment\\)\\>.*$" nil comment) ("@\\(emph\\|strong\\|b\\|i\\){[^}]+}" nil comment) ;; seems broken ;; ("\\$[^$]*\\$" nil string) ("@\\(file\\|kbd\\|key\\){[^}]+}" nil string) ("^\\*.*$" nil defun) ("@\\(if\\w+\\|format\\|item\\)\\b.*$" nil defun) ("@end +[A-Za-z0-9]+[ \t]*$" nil defun) ("@\\(samp\\|code\\|var\\){[^}]+}" nil defun) ("@\\w+\\({[^}]+}\\)?" nil keyword) )) (hilit-set-mode-patterns 'dired-mode (append '(("^D.*$" nil dired-deleted) ("^\\*.*$" nil dired-marked) ("^ d.*$" nil dired-directory) ("^ l.*$" nil dired-link) ("^ -.*#.*#$" nil dired-ignored)) (list (cons (concat "^ .*\\(" (mapconcat 'regexp-quote completion-ignored-extensions "\\|") "\\)$") '(nil dired-ignored))))) (hilit-set-mode-patterns 'jargon-mode '(("^:[^:]*:" nil jargon-entry) ("{[^}]*}+" nil jargon-xref))) (hilit-set-mode-patterns 'Info-mode '(("^\\* [^:]+:+" nil jargon-entry) ("\\*[Nn]ote\\b[^:]+:+" nil jargon-xref) (" \\(Next\\|Prev\\|Up\\):" nil jargon-xref) ("- \\(Variable\\|Function\\|Macro\\|Command\\|Special Form\\|User Option\\):.*$" nil jargon-keyword))) ; lisp manual (hilit-set-mode-patterns 'calendar-mode '(("[A-Z][a-z]+ [0-9]+" nil define) ; month and year ("S M Tu W Th F S" nil label) ; week days ("[0-9]+\\*" nil defun) ; holidays ("[0-9]+\\+" nil comment) ; diary days )) (hilit-set-mode-patterns 'pascal-mode '(("(\\*" "\\*)" comment) ("{" "}" comment) ;; Doesn't work when there are strings in comments.... ;; ("'[^']*'" nil string) ("^#.*$" nil include) ("^[ \t]*\\(procedure\\|function\\)[ \t]+\\w+[^ \t(;]*" nil defun) ("\\<\\(program\\|begin\\|end\\)\\>" nil defun) ("\\<\\(external\\|forward\\)\\>" nil include) ("\\<\\(label\\|const\\|type\\|var\\)\\>" nil define) ("\\<\\(record\\|array\\|file\\)\\>" nil type) ("\\<\\(of\\|to\\|for\\|if\\|then\\|else\\|case\\|while\\|do\\|until\\|and\\|or\\|not\\|with\\|repeat\\)\\>" nil keyword) ) nil 'case-insensitive) (hilit-set-mode-patterns 'icon-mode '(("\\(^\\|[^\\\\]\\)#.*$" nil comment) ("\\(^\\|[^\\\"]\\)\"\\([^\\\"]*\\(\\\\.[^\\\"]*\\)*_\n[ \t\n]*\\)*[^\\\"]*\\(\\\\.[^\\\"]*\\)*\"" nil string) ;; charsets: these do not work because of a conflict with strings ;;("'[^\\']*\\(\\\\.[^\\']*\\)*'" nil charset) ("^[ \t]*procedure[ \t]+[A-Za-z_0-9]+[ \t]*(" ")" defun) ("^[ \t]*record.*(" ")" include) ("^[ \t]*\\(\\$include.*$\\|\\(global\\|link\\|invocable\\)[ \t\n]+[A-Za-z_0-9]+\\([ \t\n]*,[ \t\n]*[A-Za-z_0-9]+\\)*\\)" nil include) ("^[ \t]*\\(local\\|static\\)[ \t\n]+[A-Za-z_0-9]+\\([ \t\n]*,[ \t\n]*[A-Za-z_0-9]+\\)*" nil decl) ("\\<\\(initial\\|end\\)\\>" nil glob-struct) ("^\\$[ \t]*\\(undef\\|define\\).*$" "[^\\]$" define) ("\\<\\(while\\|until\\|return\\|every\\|if\\|then\\|else\\|to\\|case\\|of\\|suspend\\|create\\|do\\|repeat\\|break\\)\\>" nil keyword) )) ;; as you can see, I had two similar problems for Pascal and Icon. In ;; Pascal, strings are delimited with ' and an embedded quote is doubled, ;; thus string syntax would be extremely simple. However, if a string ;; occurs within a comment, the following text is considered a string. ;; ;; In Icon, strings are similar to C ones, but there are also charsets, ;; delimited with simple quotes. I could not manage to use both regexps at ;; the same time. ;; ;; The problem I have with my patterns for Icon is that this language ;; has a string similar constant to the C one (but a string can be cut ;; on several lines, if terminated by an underscore and continued with ;; initial blanks, like this: ;; "This is a somewhat long _ ;; string, written on three _ ;; succesive lines" ;; in order to insert a double quote in a string, you have to escape it ;; with a \), but also a character set constant (named a charset), which ;; uses single quotes instead of double ones. It would seem intuitive to ;; highlight both constants in the same way. (provide 'hilit19) ;;; hilit19 ends here. -- Richard L. Goerwitz *** goer@midway.uchicago.edu From icon-group-sender Sun May 21 02:13:00 1995 Received: by cheltenham.cs.arizona.edu; Sun, 21 May 1995 14:09:47 MST To: icon-group-l@cs.arizona.edu Date: 21 May 1995 02:13:00 -0400 From: rdavis4@umbc.edu (R. D. Davis) Message-Id: <3pmllc$6eh@umbc8.umbc.edu> Organization: University of Maryland, Baltimore County Sender: icon-group-request@cs.arizona.edu Subject: Icon screen handling routines question Errors-To: icon-group-errors@cs.arizona.edu After picking up Icon 9.0 and getting it compiled... finally... it took a surprisingly long time to compile on a Sun 3/60 with 12 MB of memory!!! However, the compile was successful and everything seems to work; I think that I may like using Icon! :-) There's just one problem: screen handling. I noticed the routines such as iscreen, but they seem geared mainly toward terminals that can upport ANSI, such as VT-xxx terminals. The sample programs provided that use these screen handling functions don't work too well on some terminals such as my somewhat older HP-2382A terminal. :-( Worse yet, they mangle things and nothing displays properly after the programs using the screen manipulation (mangling?) code have been run. Without a good set of routines that does the type of things that curses does, which supports all the terminals that work with most UNIX systems and curses, Icon looses a great deal of appeal, unfortunately. On to other things... The graphics/X-windows part of this package seems very nice, and I'm anxious to expore it some more! (unfortunately, it's no replacement for the non-graphics terminal support that I need, however). What I like best about what I've seen of the graphics so far is that it doesn't remind me of Motif and that annoying Motif style guide. :-) One more question: has anyone ever ported a version of Icon to PERQ graphics workstations running POS or Accent, or even PNX? Are there any plans to do so? Icon on PERQs would be great! -- R. D. Davis * Eccentrics have more fun! :-) * rdavis4@umbc.edu, rdd@mystica.uucp > Home telephone: 1-410-744-7964 > Vintage computer fanatic and http://www.access.digex.net/~rdd > preservationist. From icon-group-sender Sun May 21 16:05:29 1995 Received: by cheltenham.cs.arizona.edu; Sun, 21 May 1995 14:11:35 MST To: icon-group-l@cs.arizona.edu Date: Sun, 21 May 1995 16:05:29 GMT From: goer@quads.uchicago.edu (Richard L. Goerwitz) Message-Id: Organization: The University of Chicago Sender: icon-group-request@cs.arizona.edu References: <3pmllc$6eh@umbc8.umbc.edu> Reply-To: goer@midway.uchicago.edu Subject: Long response re Icon screen handling routines Errors-To: icon-group-errors@cs.arizona.edu In article <3pmllc$6eh@umbc8.umbc.edu>, R. D. Davis wrote: > >There's just one problem: screen handling. I noticed the routines >such as iscreen, but they seem geared mainly toward terminals that can >upport ANSI, such as VT-xxx terminals. Those routines are just bare minimums. The low-level library is iolib.icn, and it will support anything your termcap file will support. But these are low-level routines. There is no high-level curses for Icon. Nor will there be - unless you write it :-). Once upon a time, a couple of entrepreneurs built a really nice, commercial version of Icon that had marvellous support for character-based terminals. But sales were, well, abysmal. There were no apps to show off its capabilities, and the system only ran on i386 machines, as I recall. I was sad to see it go, but there was just no market for it. Nowadays, if this project were done again, I don't think the extensions would be built into the base Icon run-time system, but rather into dynam- ically loadable libraries. For some time now, Icon has suffered from feeping creaturism, and its maintainers have been trying to keep down its size and concentrate their remaining resources on porting and the graphics facilities. Once you get the hang of it, Icon is one of the easiest environments to work in anywhere. As one fellow said to me, programmers become religiously attached to their environments. Although I do most of my programming in C these days, I still feel a certain sadness that I can't do everything in Icon. I'm afraid that if you want to do curses-like stuff, you will be back with C, too - unless you want to write a set of Icon screen hand- ling routines. -- Richard L. Goerwitz *** goer@midway.uchicago.edu From icon-group-sender Mon May 22 04:05:11 1995 Received: by cheltenham.cs.arizona.edu; Mon, 22 May 1995 09:26:23 MST Date: 22 May 95 12:03:49 BST From: R J Hare Subject: Graphics problem To: icon-group@cs.arizona.edu Organisation: Edinburgh University Computing Service Message-Id: <9505221203.aa15824@uk.ac.ed.festival> Errors-To: icon-group-errors@cs.arizona.edu Probably a very simple answer to this, but I don't know what it is, so here goes: I have an Icon graphics application where I save a display to a .gif file and then use xv to convert the gif file to .ps before printing. Now, I have my background set to the default white, but when I print the .ps file, the background is very light gray. Why is white not white in this case? Thanks. Roger Hare. From icon-group-sender Mon May 22 20:38:50 1995 Received: by cheltenham.cs.arizona.edu; Tue, 23 May 1995 08:52:35 MST To: icon-group-l@cs.arizona.edu Date: 22 May 1995 20:38:50 GMT From: Rick Riolo Message-Id: <3pqsor$4fd@controversy.admin.lsa.umich.edu> Organization: Program for Study of Complex Systems (PSCS) Sender: icon-group-request@cs.arizona.edu Subject: (no subject) Errors-To: icon-group-errors@cs.arizona.edu I am having a problem compiling with iconc (sometimes...). The uncompiled version of this app goes thru icont and runs just fine on my hp. This same app also compiles under a sun/os using sun's cc. But on my hpux 9.05 (715/100,64M-RAM) system, its failing as follwos: maria-rlr)time iconc -fa -p'-v' regress ../gpmain Translating to C: regress.icn: ./gpmain.icn: /s/users/rlr/GRASS/Icon/icon-gp-0.7/pop.icn: /s/users/rlr/GRASS/Icon/icon-gp-0.7/prog.icn: /s/users/rlr/GRASS/Icon/icon-gp-0.7/lang.icn: /s/users/rlr/GRASS/Icon/icon-gp-0.7/src.icn: /s/users/rlr/GRASS/Icon/icon-gp-0.7/rand.icn: /s/users/rlr/GRASS/Icon/icon-gp-0.7/Libes/adt_wl.icn: /s/users/rlr/GRASS/Icon/icon-gp-0.7/params.icn: /s/users/rlr/GRASS/Icon/icon-gp-0.7/fc.icn: /s/users/rlr/GRASS/Icon/icon-gp-0.7/profile.icn: /s/users/rlr/GRASS/Icon/icon-gp-0.7/Grammar/cfrule.icn: /s/users/rlr/GRASS/Icon/icon-gp-0.7/Grammar/lex.icn: /usr/local/Icon/ipl/procs/options.icn: /usr/local/Icon/ipl/procs/printf.icn: /s/users/rlr/GRASS/Icon/icon-gp-0.7/Grammar/cfnet.icn: /s/users/rlr/GRASS/Icon/icon-gp-0.7/Libes/adt_str.icn: /s/users/rlr/GRASS/Icon/icon-gp-0.7/Grammar/cfnode.icn: No errors; no warnings Compiling and linking C code: *** C compile and link failed *** 175.34u 1.20s 2:57.44 99.4% maria-rlr) The -v'-p' to the hp's cc is supposed to have it emit verbose messages about what its doing. As you can see, there was no useful messages when it failed. I have iconc -c and the files are: -rw-rw-r-- 1 rlr appl 957232 May 12 08:50 regress-x.c -rw-rw-r-- 1 rlr appl 123207 May 12 08:50 regress-x.h (the regress-x.* is just me putting them on the side...) Pretty big (by icon scales, I don't know if that is big or not, being an icon newbie). I have plenty of filespace (3G) in the cwd and in /tmp and /usr/tmp . A further complication: Once time when I did this same command, it successfully compiled! No changes to the source, just ran iconc again. That time the -p'-v' did emit messages from hp's cc&friends. (So maybe I can use those commands to see what's going on...) that suggests some resource-dependent problem, varying with when I try to to the iconc. maybe...but which resource? (also, I'm the only one using it...) A few questions: - is there any way I can get iconc to tell me what cc and ld &etc commands its emitting (when it fails)? - is there any way to get better messages? (i tried the -v4 on the iconc above, but that seems only to increase verbosity of icn->c part. - by default iconc was made to use hp's cc. I have gcc. Is there a way (short of remake of iconc) to tell iconc to use gcc instead of cc? and - Any ideas what might be causing this? eg maybe hp's cc is croaking on the big .c/.h files? (I looked thru man cc, but didn't see anything...but its long of course and I could have missed something) thanks for any advice you can give. - r --------------------- An addendum: I tried an iconc -c and got the classify.c/.h files as mentioned before. (last time I did regress: classify is a similar app...differs by one file... that has been having the same iconc problem.) then I use cpp,ccom and ld commands I got the one time iconc -fa -p'-v' regress ../gpmain worked (modified to compile classify): maria-rlr)/lib/cpp classify.c /tmp/x -$ -D__hp9000s700 -D__hp9000s800 -D__hppa -D__hpux -D__unix -D_PA_ RISC1_1 maria-rlr)dir /tmp/x -rw-rw-r-- 1 rlr appl 1266167 May 12 14:02 /tmp/x maria-rlr)/lib/ccom /tmp/x classify.o -Oq00,al,ag,cn,Lm,sz,Ic,vo,lc,mf,Po,es,rs,sp,in,pi,fa,pe,Rr,Fl! -Ac maria-rlr)dir classify.o /tmp/x -rw-rw-r-- 1 rlr appl 1266167 May 12 14:02 /tmp/x -rw-rw-r-- 1 rlr appl 623972 May 12 14:02 classify.o maria-rlr)/bin/ld /lib/crt0.o -u main -Fb /usr/lib/uccom -L/usr/lib/X11R5 -L/lib -o classify classify.o /usr/local/Icon/bin/rt.a -L/usr/local/Icon/bin/ -lXpm -lX11 -lm -lc maria-rlr)dir classify -rwxrwxr-x 1 rlr appl 1085440 May 12 14:03 classify maria-rlr) (some of the odd wrapping is just my mailer... I haven't looked at all the pars its sending to the cc parts... some look odd, eg -D__hp9000s700 -D__hp9000s800 but I don't know the hp cc compiler that well...) At any rate, as you can see, the cpp output is in /tmp/x. There are no errors at any step, and when all is done, the compiled classify runs! I then immediately tried iconc -fa classify ../gpmain and it fails again, with the same old (non-)message: .. No errors; no warnings Compiling and linking C code: *** C compile and link failed *** maria-rlr) So....I am further puzzled by it all. thanks for any suggested steps to take to figure out what's going on. -r -- Rick Riolo rlriolo@umich.edu Program for Study of Complex Systems (PSCS) 1071 Randall Lab University of Michigan Ann Arbor MI 48109-1120 From icon-group-sender Wed May 24 05:04:42 1995 Received: by cheltenham.cs.arizona.edu; Wed, 24 May 1995 07:01:55 MST To: icon-group-l@cs.arizona.edu Date: 24 May 1995 05:04:42 GMT From: porco@pathos.Berkeley.EDU (Travis C. Porco) Message-Id: <3puepa$86k@agate.berkeley.edu> Organization: University of California, Berkeley Sender: icon-group-request@cs.arizona.edu References: <3p9g5g$4l2@goanna.cs.rmit.edu.au>, <3pc58h$htb@news.computek.net> Subject: Re: icon notes [Re: Is there such a language...] Errors-To: icon-group-errors@cs.arizona.edu In article <3pc58h$htb@news.computek.net>, wrote: +> :ICON programmers should be actively promoting the language they love: making +> :code reservoirs, cool ways of doing things,etc.. I see none of that. +> +> But they *DO*. I have seen quite a bit of code posted to comp.lang.icon +> over the last couple of years, and user-contributed Icon code _is_ held +> at cs.arizona. It isn't hard to find: cd icon and follow the READ.MEs. +> +> :Or they should have an active newsgroup, interactive newsletters, etc to tell +> :the world their accomplishments. + +Well, I lived in Paris for almost nine years, and during that time I helped organize a +visit of Madge Griswold (co-author of the Icon book) to talk to a large computer +club; managed to get an echo of the Icon newsgroup on a popular local BBS; +and also frequently discussed both SNOBOL4+ and Icon on lots of international +echo conferences. I entered Icon or SNOBOL4+ programs into several BBS +programming competitions. I managed to get a couple of local programmers interested, +but most seemed stuck on their stupid Perl garbage (who needs it, if you have +SNOBOL4+ and Icon?????). After lots of mostly unsuccessful attempts, I finally +just gave up and decided to keep it to myself... my secret weapon in the Consulting +Wars. :-) + +I can come in after another consultant, and often do a project in two days that +the other guy has said will take him one or two months... even if I charged two or +three times as much for my time as he does, I can still solve the client's problem for +less money, and get the solution to him sooner. And when a client is paying for a +programmer by the day, I've NEVER YET had a client insist that I write the thing in +C or something more common, instead of SNOBOL4+. + +> Let's see: Fortran is still alive, COBOL is still alive, Basic is still +> alive, MUMPS is still alive, APL is still alive, Lisp is still alive, +> people are _still_ (much to my astonishment) using Jovial, I've got a +> SNOBOL system so SNOBOL is still alive.... + +Actually, for everyday programming tasks, I personally still prefer SNOBOL4+ to +Icon. I just think it's easier to use, unless I need character sets or combinatorial +things or some of the other special features of Icon. + + Tell us more. I find Icon fascinating, but it is so intricate in some ways and so different that it would take me a _long_ time of stumbling in the dark to learn how to use it effectively. I'd consider paying anyone who could show me tricks, techniques, tips. After all, there aren't hundreds of books on this fascinating language, and I'm not a big one to reinvent the wheel. So share with us details, case studies, tips, tricks if you like; many of us lurkers would like to see this sort of thing. In particular, how is Snobol preferable to Icon for some tasks? Both are interesting languages and a non-flame-war comparison might shed light on both. --Travis From icon-group-sender Wed May 24 08:43:46 1995 Received: by cheltenham.cs.arizona.edu; Wed, 24 May 1995 07:04:13 MST To: icon-group-l@cs.arizona.edu Date: 24 May 1995 08:43:46 -0400 From: jwalsh@nova.umuc.edu (thirtysomething) Message-Id: <3pv9m2$n57@nova.umuc.edu> Organization: University of Maryland University College Sender: icon-group-request@cs.arizona.edu References: <3p9g5g$4l2@goanna.cs.rmit.edu.au>, <3pc58h$htb@news.computek.net>, <3puepa$86k@agate.berkeley.edu> Subject: Re: icon notes [Re: Is there such a language...] Errors-To: icon-group-errors@cs.arizona.edu In article <3pc58h$htb@news.computek.net>, wrote: +I can come in after another consultant, and often do a project in two days that +the other guy has said will take him one or two months... even if I charged two or +three times as much for my time as he does, I can still solve the client's problem for +less money, and get the solution to him sooner. And when a client is paying for a +programmer by the day, I've NEVER YET had a client insist that I write the thing in +C or something more common, instead of SNOBOL4+. I agree that Icon can run circles around C and similar languages. And I'm all for working smarter and charging higher rates for my time. :-) But... Does the Icon compiler produce native (machine) code? Execution performance is still an issue for many, although I agree that it is becoming *less* of an issue. And can I leave a copy of the compiler with the client? From icon-group-sender Wed May 24 11:40:00 1995 Received: by cheltenham.cs.arizona.edu; Wed, 24 May 1995 11:01:40 MST Message-Id: <9505241140.AA03879@ns1.computek.net> Mime-Version: 1.0 Content-Length: 1829 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 24 May 95 11:40 CDT From: gep2@computek.net Subject: Re: icon notes [Re: Is there such a language...] To: icon-group@cs.arizona.edu X-Mailer: SPRY Mail Version: 04.00.06.14 Errors-To: icon-group-errors@cs.arizona.edu >I agree that Icon can run circles around C and similar languages. And I'm all for working smarter and charging higher rates for my time. :-) >But... Does the Icon compiler produce native (machine) code? Execution performance is still an issue for many, although I agree that it is becoming *less* of an issue. It all really depends on what kind of a program you're going to write. Some programs will only [finally] run ONCE, or at least very infrequently: a good example is a SNOBOL4+ program I'm writing at the moment which will take a large series of Excel spreadsheets (almost 5300 cells) and cross-compile it into a source program in the PCBUS programming language (so it can be more tightly integrated into a larger business applications system). I expect this cross-compiler program will take me three or four days to write and test; the final run (to produce the Databus source program) will probably take (maybe much) less than five or ten minutes. In most cases nowadays, at least for programs you won't be running in many examples and on many occasions, the cost of writing a computer program is hugely more than the cost of running it. >And can I leave a copy of the compiler with the client? In the case of ICON, you most probably can: the ICON compiler (with the exception of some perhaps commercial adaptations of it) is public domain. SNOBOL4+ is a commercial product, so you can't leave a copy of that... but it comes with a royalty-free runtime which you CAN leave with them. And of course, the other option is to just buy a copy of the compiler for them: at $100 (I think it's somewhat more than that today), it's unquestionably the best (and also the most durable) productivity software investment I have -ever- made. Gordon Peterson http://www.computek.net/public/gep2  From icon-group-sender Wed May 24 11:58:00 1995 Received: by cheltenham.cs.arizona.edu; Wed, 24 May 1995 11:02:29 MST Message-Id: <9505241158.AA04986@ns1.computek.net> Mime-Version: 1.0 Content-Length: 3128 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 24 May 95 11:58 CDT From: gep2@computek.net Subject: Re: icon notes [Re: Is there such a language...] To: icon-group@cs.arizona.edu X-Mailer: SPRY Mail Version: 04.00.06.14 Errors-To: icon-group-errors@cs.arizona.edu >+Actually, for everyday programming tasks, I personally still prefer SNOBOL4+ to Icon. I just think it's easier to use, unless I need character sets or combinatorial things or some of the other special features of Icon. >Tell us more. I find Icon fascinating, but it is so intricate in some ways and so different that it would take me a _long_ time of stumbling in the dark to learn how to use it effectively. Well, you don't HAVE to use all the intricate things in ICON. Most people, I'd expect, start programming ICON in much the same way they would program in C, and then sort of "grow into" its special higher-level features and paradigms as they get more comfortable in the language. The ICON book is a pretty good introduction to the language, I think. >I'd consider paying anyone who could show me tricks, techniques, tips. After all, there aren't hundreds of books on this fascinating language, and I'm not a big one to reinvent the wheel. If you're interested in SNOBOL4, there's a WONDERFUL book showing you just exactly that for the SNOBOL4 language. It's called "Algorithms in SNOBOL4" written by Gimpel (the same Gimpel who's responsible for C-Lint) and is available from Catspaw, Inc. in Salida, Colorado (the people who did SNOBOL4+ and now their newer Spitbol products). The book is only about $20 I think, and it's a -terrific- buy for the money. >So share with us details, case studies, tips, tricks if you like; many of us lurkers would like to see this sort of thing. That book is a far more wonderful collection of tricks and tips than anything I could ever hope to post here. And of course, there's the other side: once you are somewhat familiar with the language, "tips and tricks" are so UNhidden and so obvious that I suspect most of us don't think it's particularly worth sharing something so obvious. But I think it's fair to say that all of us who use and love either ICON or SNOBOL4 have had so often the exhilaration of seeing an otherwise complex problem solved, simply and elegantly, that it explains the almost religious reverence that we have for these marvelous languages. >In particular, how is Snobol preferable to Icon for some tasks? Well, for example, SNOBOL4 supports two extraordinarily interesting functions: eval(), which evaluates expressions, possibly containing symbols; and code(), which converts an arbitrarily long character string containing SNOBOL4 source code (even containing labels if you like, which you can reference externally) to compiled object code (which you can later execute as often and as many times as you like). These are NOT preprocessor functions: they are available at runtime. There is no equivalent capability in ICON. The other major thing is that I personally find SNOBOL4's pattern matching to be simpler and more intuitive (although admittedly ultimately less powerful) than ICON's string scanning. Of course, ICON also has a LOT of things that SNOBOL4 doesn't have... as with so many other things in life, there are always tradeoffs. Gordon Peterson http://www.computek.net/public/gep2  From icon-group-sender Wed May 24 16:21:25 1995 Received: by cheltenham.cs.arizona.edu; Wed, 24 May 1995 17:39:22 MST From: mitch@roll.csd.sgi.com (Tom Mitchell) Message-Id: <199505242321.QAA14130@roll.csd.sgi.com> Subject: Re: icon notes [Re: Is there such a language...] To: gep2@computek.net Date: Wed, 24 May 1995 16:21:25 -0700 (PDT) Cc: icon-group@cs.arizona.edu In-Reply-To: <9505241140.AA03879@ns1.computek.net> from "gep2@computek.net" at May 24, 95 11:40:00 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 968 Errors-To: icon-group-errors@cs.arizona.edu > > >I agree that Icon can run circles around C and similar languages. And I'm > all for working smarter and charging higher rates for my time. :-) > > >But... > Does the Icon compiler produce native (machine) code? Execution > performance is still an issue for many, although I agree that it > is becoming *less* of an issue. > Interpreted languages have many advantages over "native code". Speed need not be an advantage of "native code". An interpreter that is structured and sized to behave well in a cache can run faster than native code that does not fit. It is sort of the old religion of CISC vs. RISC so lets avoid that distraction. But perhaps more important are two things: 1) The portability and availability that an interpreter can provide. In this regard Perl is just such a win. Regardless of the hardwre or OS system only the interpreter need be ported. 2) The richness of the language and the abstraction it provides. From icon-group-sender Wed May 24 18:45:00 1995 Received: by cheltenham.cs.arizona.edu; Wed, 24 May 1995 17:40:26 MST Message-Id: <9505241845.AA16793@ns1.computek.net> Mime-Version: 1.0 Content-Length: 1620 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 24 May 95 18:45 CDT From: gep2@computek.net Subject: Re: icon notes [Re: Is there such a language...] To: icon-group@cs.arizona.edu X-Mailer: SPRY Mail Version: 04.00.06.14 Errors-To: icon-group-errors@cs.arizona.edu >Interpreted languages have many advantages over "native code". I certainly agree. I worked for more than nine years at Datapoint, and our Datashare system there was better in many ways than a direct-executing system could have been. >Speed need not be an advantage of "native code". An interpreter that is structured and sized to behave well in a cache can run faster than native code that does not fit. That's unlikely to be the main reason, but there are others... including the fact that you can sometimes start to execute a program before it is entirely loaded, and some parts (particularly those which are involved in handling exceptional conditions or unused program options) may not even EVER be loaded. It also makes it easier to provide corrected runtime libraries without having to modify compiled programs... and leaving all that common code out of compiled programs, leaving just one copy on your hard drive, no matter how many applications you have that uses it. >But perhaps more important are two things: > 1) The portability and availability that an interpreter can provide. In this regard Perl is just such a win. Well, that's perhaps a poor example since Perl is such a piece of rubbish, compared to either SNOBOL4 or ICON. I can't much imagine why anybody here would DREAM of wasting time learning or using Perl. 2) The richness of the language and the abstraction it provides. Certainly either ICON or SNOBOL4 are a revelation to anybody who's previously only dealt with primitive languages like C or Pascal. Gordon Peterson http://www.computek.net/public/gep2  From icon-group-sender Sun May 28 21:23:08 1995 Received: by cheltenham.cs.arizona.edu; Mon, 29 May 1995 13:25:48 MST From: Phil Bralich To: icon-group@cs.arizona.edu Subject: Machine Usable Dictionary Content-Length: 1694 Message-Id: <95May28.212314hst.97208@uhunix2.uhcc.Hawaii.Edu> Date: Sun, 28 May 1995 21:23:08 -1000 Errors-To: icon-group-errors@cs.arizona.edu As you may know from postings I have made to this list over the last couple of months, Derek Bickerton and I are developing a parser based on a theory of syntax that he and I have been developing over the last four years. We are about to purchase a machine usable dictionary with approximately 70,000 entries for $2500. If anyone could advise us whether or not that is our best bet, or where we might find other dictionaries, we would appreciate hearing from you. We are currently working with a dictionary of under 1000 words, so it is imperative that we obtain a larger one, so we may begin working with larger corpora. Toward that end we would also like to find out which texts were used in past parsing competitions and where the results of these competitions are published. We believe that with a few weeks of work we should be able to modify a dictionary sufficiently to allow us to begin experinmenting with texts that were used in past parsing competitions. Here are the specs the parser. It is based on a series of algorithms that have been four years in the making, but the programming required to create this parser has only taken 300 hours using C++ . There areapproximately 3000 lines of code that take up 150k executable on disk. About 100k of RAM is required to run the parser. 30k on disk is required for a 300 word dictionary. An average sentence takes under 4 seconds to process on a 486 IBM compatible. Since this is only a development version, we expect these numbers to change. To date, no optimizations have occurred, and we expect to significantly shrink the dictionary disk usage and the execution time. Phil Bralich bralich@uhccux.uhcc.Hawaii.edu From icon-group-sender Tue May 30 20:36:41 1995 Received: by cheltenham.cs.arizona.edu; Tue, 30 May 1995 08:39:07 MST To: icon-group-l@cs.arizona.edu Date: 30 May 1995 20:36:41 +1000 From: ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) Message-Id: <3qesfp$bhj@goanna.cs.rmit.edu.au> Organization: Comp Sci, RMIT, Melbourne, Australia Sender: icon-group-request@cs.arizona.edu References: <3pc58h$htb@news.computek.net>, <3puepa$86k@agate.berkeley.edu>, <3pv9m2$n57@nova.umuc.edu> Subject: Re: icon notes [Re: Is there such a language...] Errors-To: icon-group-errors@cs.arizona.edu jwalsh@nova.umuc.edu (thirtysomething) writes: >Does the Icon compiler produce native (machine) code? Execution >performance is still an issue for many, although I agree that it >is becoming *less* of an issue. Yes. It is called 'iconc'. >And can I leave a copy of the compiler with the client? Yes. It costs as much as the rest of Icon (= $0.00). -- "The complex-type shall be a simple-type." ISO 10206:1991 (Extended Pascal) Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci. From icon-group-sender Tue May 30 13:54:45 1995 Received: by cheltenham.cs.arizona.edu; Tue, 30 May 1995 08:39:45 MST To: icon-group-l@cs.arizona.edu Date: Tue, 30 May 1995 13:54:45 GMT From: goer@quads.uchicago.edu (Richard L. Goerwitz) Message-Id: Organization: The University of Chicago Sender: icon-group-request@cs.arizona.edu References: <3puepa$86k@agate.berkeley.edu>, <3pv9m2$n57@nova.umuc.edu>, <3qesfp$bhj@goanna.cs.rmit.edu.au> Reply-To: goer@midway.uchicago.edu Subject: Re: icon notes [Re: Is there such a language...] Errors-To: icon-group-errors@cs.arizona.edu Richard A. O'Keefe wrote: >>Does the Icon compiler produce native (machine) code? > >Yes. It is called 'iconc'. But the executables tend to be rather large, and in most cases you're better off using the interpreter. To the user there is no difference except execution speed. And the in- terpreter is much easier to deal with (older, more reliable, faster to create executables, etc.). -- Richard L. Goerwitz *** goer@midway.uchicago.edu From icon-group-sender Tue May 30 14:57:03 1995 Received: by cheltenham.cs.arizona.edu; Tue, 30 May 1995 12:13:01 MST To: icon-group-l@cs.arizona.edu Date: 30 May 1995 14:57:03 GMT From: espie@lotus.ens.fr (Marc Espie) Message-Id: <3qfbnv$fjr@nef.ens.fr> Organization: Ecole Normale Superieure, PARIS, France Sender: icon-group-request@cs.arizona.edu References: <3pv9m2$n57@nova.umuc.edu>, <3qesfp$bhj@goanna.cs.rmit.edu.au>, Subject: Re: icon notes [Re: Is there such a language...] Errors-To: icon-group-errors@cs.arizona.edu In article , Richard L. Goerwitz wrote: >Richard A. O'Keefe wrote: > >>>Does the Icon compiler produce native (machine) code? >> >>Yes. It is called 'iconc'. > >But the executables tend to be rather large, and in most >cases you're better off using the interpreter. To the user >there is no difference except execution speed. And the in- >terpreter is much easier to deal with (older, more reliable, >faster to create executables, etc.). > Except for icon Makefiles looking like tangled spaghettis, it's rather easy to get icon to use shared dynamic libraries on modern architectures like Sparc, in which case the whole runtime gets shared and the code size gets down somewhat. The other problem is more drastic: the icon compiler is not supported, since the Icon Project doesn't have enough support for doing it, it doesn't support separate compilation, and really interesting optimizations are not implementing (like downgrading icon integers to real C integers). Oh yes... and there might be some bugs in the type inferencing compiler as well... All this notwithstanding, there are still some cases when compiling is useful... For some rather intensive combinatorial programs, I've got a 3x speed-up, going down from 24 hours to 8 hours, and it's always fun to use the compiler (Wow! 80 000 lines of C code, iconc making 10 passes of type inferencing, gobbling up 30 Megs of memory :-) ). Actually the answer is incorrect: iconc produces intermediate C code, that is compiled by the machine native compiler (or gcc in most cases). Using -p "-O2" with iconc helps getting fast executables. This might explain why you got nearly no improvement when using iconc. -- [nosave] `Ayuka no koto... suki dayo.' (KOR, Ano Hi ni kaeritai) `$@0>@n(J $@$N$3$H!<9%$-$@$h!#(J' ($@$"$NF|$K5"$j$?$$(J)(B Marc Espie (Marc.Espie@ens.fr) From icon-group-sender Wed May 31 13:53:35 1995 Received: by cheltenham.cs.arizona.edu; Thu, 1 Jun 1995 10:38:30 MST To: icon-group-l@cs.arizona.edu Date: 31 May 1995 13:53:35 -0700 From: dave@cs.arizona.edu (Dave Schaumann) Message-Id: <3qil0f$dnd@lectura.CS.Arizona.EDU> Organization: University of Arizona CS Department, Tucson AZ Sender: icon-group-request@cs.arizona.edu References: Subject: Re: problem with 'key' Errors-To: icon-group-errors@cs.arizona.edu In article , Jens Krinke wrote: >Hi, > >i have a problem with 'key': example: > >record test(foo, bar) > >procedure main() > a := table() > a[test(3,4)] := "a(3,4)" > a[test(1,2)] := "a(1,2)" > every write("entry: ", image(!a)) > every write("key: ", image(!key(a))) ^ > every k := !key(a) do ^ > write("check: ", image(a[k])) "key" is already a generator -- there's no need to use the '!' operator with it. The reason you are getting the results you are is that key() returns first the record "a(1,2)". Then '!' causes iteration over the fields of that record, giving the result you see in the first loop. Similarly in the second loop, 'k' goes over the values 1, 2, 3, and 4. None of these are keys in your table, and so all references have the default (&null) value. -Dave From icon-group-sender Sat Jun 3 21:29:37 1995 Received: by cheltenham.cs.arizona.edu; Mon, 5 Jun 1995 08:57:22 MST To: icon-group-l@cs.arizona.edu Date: 3 Jun 1995 21:29:37 -0400 From: davidf@deci.mks.com (David J. Fiander) Message-Id: <3qr2a1$afq@deci.mks.com> Organization: Mortice Kern System, Inc. Sender: icon-group-request@cs.arizona.edu Subject: Garbage collection vs files Errors-To: icon-group-errors@cs.arizona.edu Most lisps will properly close files during garbage collection. Does iconx, or the code generated by iconc? - David From icon-group-sender Sun Jun 4 02:42:45 1995 Received: by cheltenham.cs.arizona.edu; Mon, 5 Jun 1995 08:57:07 MST To: icon-group-l@cs.arizona.edu Date: 4 Jun 1995 02:42:45 GMT From: Justin Risser Message-Id: <3qr6j5$5kn@grape.epix.net> Organization: epix.net Sender: icon-group-request@cs.arizona.edu Subject: Icons Errors-To: icon-group-errors@cs.arizona.edu Is there a utility that extracts ico files from icl file libraries... Could you tell me of a www site where I could get something like that... Justin Risser From icon-group-sender Tue May 30 16:31:09 1995 Received: by cheltenham.cs.arizona.edu; Mon, 5 Jun 1995 08:57:37 MST To: icon-group-l@cs.arizona.edu Date: Tue, 30 May 1995 16:31:09 GMT From: krinke@infbspsk.cs.tu-bs.de (Jens Krinke) Message-Id: Organization: TU Braunschweig, FRG Sender: icon-group-request@cs.arizona.edu Reply-To: krinke@ips.cs.tu-bs.de (Jens Krinke) Subject: problem with 'key' Errors-To: icon-group-errors@cs.arizona.edu Hi, i have a problem with 'key': example: record test(foo, bar) procedure main() a := table() a[test(3,4)] := "a(3,4)" a[test(1,2)] := "a(1,2)" every write("entry: ", image(!a)) every write("key: ", image(!key(a))) every k := !key(a) do write("check: ", image(a[k])) end results in: entry: "a(1,2)" entry: "a(3,4)" key: 1 key: 2 key: 3 key: 4 check: &null check: &null check: &null check: &null what am I doing wrong? Shouldn't the exact output be: entry: "a(1,2)" entry: "a(3,4)" key: record_test... key: record_test... check: "a(1,2)" check: "a(3,4)" Thanks, Jens -- ____________________________________________________________________ Jens Krinke (krinke@ips.cs.tu-bs.de, http://www.cs.tu-bs.de/~krinke) From icon-group-sender Mon Jun 5 10:58:00 1995 Received: by cheltenham.cs.arizona.edu; Mon, 5 Jun 1995 09:46:05 MST Message-Id: Date: Mon, 5 Jun 95 10:58 CDT From: escargo@mirage.skypoint.com To: icon-project@cs.arizona.edu Subject: Icon 9.0 with MSC 7.0 Content-Length: 600 Errors-To: icon-group-errors@cs.arizona.edu I'm trying to rebuild Icon 9.0 using my Microsoft C 7.0 compiler. I have the large memory libraries installed. When I do the common build.bat step I get warning messages compiling time.c: lines 214, 215, and 346 all yield warning C4049: 'argument' : indirection to different types. I tried running the build.bat for common, icont, and iconx, but did not achieve successful completions. The status file for msc7 says that 8.10 was the latest version. I understand that msc is not the favored compiler. Is there an MSC expert I can talk to about getting 9.00 compiled under MSC7? David S. Cargo From icon-group-sender Mon Jun 5 20:39:02 1995 Received: by cheltenham.cs.arizona.edu; Mon, 5 Jun 1995 16:20:47 MST To: icon-group-l@cs.arizona.edu Date: Mon, 5 Jun 1995 20:39:02 GMT From: ka@socrates.hr.att.com (Kenneth Almquist) Message-Id: Organization: AT&T Sender: icon-group-request@cs.arizona.edu References: <3qr2a1$afq@deci.mks.com> Subject: Garbage collection vs files Errors-To: icon-group-errors@cs.arizona.edu > Most lisps will properly close files during garbage collection. > Does iconx, or the code generated by iconc? No, or at least it didn't last time I checked. To close a file in Icon, you must call "close". The problem with relying on garbage collection to close files is that if your program opens files frequently, it may hit the limit on the maximum number of open files between invocations of the garbage collector. If the garbage collector is invoked by the open routine when the limit is hit, the result may be an excessive number of garbage collections. Kenneth Almquist From icon-group-sender Wed Jun 7 04:46:24 1995 Received: by cheltenham.cs.arizona.edu; Wed, 7 Jun 1995 08:20:57 MST From: Nevin Liber Message-Id: <199506071147.EAA10758@lectura.CS.Arizona.EDU> Subject: Re: Garbage collection vs files To: davidf@deci.mks.com (David J. Fiander) Date: Wed, 7 Jun 1995 04:46:24 -0700 (MST) Cc: icon-group-l@cs.arizona.edu In-Reply-To: <3qr2a1$afq@deci.mks.com> from "David J. Fiander" at Jun 3, 95 09:29:37 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2227 Sender: nevin@lectura Errors-To: icon-group-errors@cs.arizona.edu davidf@deci.mks.com (David J. Fiander) writes: > Most lisps will properly close files during garbage collection. > Does iconx, or the code generated by iconc? No. I'm not sure why you would want to. I can see doing it under LISP, since there is usually an interactive programming environment associated with it. There is no such environment associated with Icon. Also, closing open files at garbage collection time is not correct semantically speaking, since the program itself might be dependent on the underlying file system semantics. For instance, on a local Unix disk (this is also hacked into NFS, but I digress), one is allowed to open a file and then remove it (technically, remove its directory entry), and still access the file until it is closed or the program terminates. This is guaranteed for a Unix filesystem, and closing an open file descriptor at garbage collection time would break these semantics. (One could argue that one should not be dependent on tricks like this, but that is beyond the scope of this discussion.) On a related note: whenever I write a tool that takes a bunch of file names from the command line, or reads from &input if none are specified, I use a variation of the following routine: procedure InputFiles(LInputFilenames[]) local sFilename local fInput if 0 = *LInputFilenames then { return &input } while sFilename := get(LInputFilenames) do { if not (fInput := open(string(sFilename))) then { write(&errout, &progname, ": cannot open ", image(sFilename), " for reading.") next } suspend fInput close(fInput) } end And the caller looks something like: procedure main(LArguments) local fFile ... every fFile := InputFiles ! LArguments do { ProcessFile(fFile) } This way, I am sure to close all the files that I open, I don't close &input (I don't like to close files that I didn't open), and all the code to handle the case where there are no files specified on the command line is isolated to InputFiles(). -- Nevin ":-)" Liber nevin@cs.arizona.edu (520) 293-2799 office: (520) 621-1815 From icon-group-sender Thu Jun 8 14:52:07 1995 Received: by cheltenham.cs.arizona.edu; Thu, 8 Jun 1995 09:36:03 MST To: icon-group@cs.arizona.edu Date: 8 Jun 1995 14:52:07 GMT From: ruiter@ruls41.fsw.LeidenUniv.nl (Jan-Peter de Ruiter) Message-Id: <3r72qn$kim@highway.LeidenUniv.nl> Organization: Leiden University, The Netherlands Sender: icon-group-request@cs.arizona.edu Subject: implementation of integers in Icon Errors-To: icon-group-errors@cs.arizona.edu Is there any information available that explains how in Icon (infinite) integers are represented and processed? It isn't in the implementation book, and I'm hoping to avoid looking at the code of the implementation. Thanks in advance for any help, Jan From icon-group-sender Thu Jun 8 11:01:25 1995 Received: by cheltenham.cs.arizona.edu; Thu, 8 Jun 1995 12:39:58 MST Date: Thu, 08 Jun 1995 11:01:25 -0500 From: "Mark B. Emmer" Subject: Re: implementation of integers in Icon To: "icon-group@cs.arizona.edu" Message-Id: <01HRGQGSZLIA985KIR@MAILSRV1.PCY.MCI.NET> X-Mailer: e-mailMCI v2.3 Content-Transfer-Encoding: 7BIT Errors-To: icon-group-errors@cs.arizona.edu -- [ From: Mark B. Emmer * EMC.Ver #2.3 ] -- > Is there any information available that explains how in Icon (infinite) > integers are represented and processed? Large integers are stored in a b_bignum struct, which has a few header words, and then an array of ints. In 32-bit implementations, each array element holds a 16-bit "digit", so the number is stored in base 65536 form. The b_bignum block will vary in size with the magnitude of the number. If you have the source, examine b_bignum in rstructs.h, and the code for manipulating large integers in rlrgint.r or rlrgint.c (depending upon the age of your source). Although some of the boundary conditions that the code has to worry about are arcane, overall it's a fairly readable piece of code. -- Mark From icon-group-sender Thu Jun 15 20:12:06 1995 Received: by cheltenham.cs.arizona.edu; Fri, 16 Jun 1995 08:54:28 MST To: icon-group@cs.arizona.edu Date: 15 Jun 1995 20:12:06 -0700 From: scott@cs.arizona.edu (Scott E Gilbert) Message-Id: <3rqsq6$g9s@lectura.CS.Arizona.EDU> Organization: University of Arizona CS Department, Tucson AZ Sender: icon-group-request@cs.arizona.edu References: <3rpcmd$ie0@canopus.cc.umanitoba.ca> Subject: Re: ICON vs Ted Nelson Errors-To: icon-group-errors@cs.arizona.edu In article <3rpcmd$ie0@canopus.cc.umanitoba.ca>, wrote: >I am just wondering whether or not anyone posts any ICON related info here. It currently sounds more >like the TED Nelson pro / con list! Maybe u could start a new list for the the letter and its responses, hmm! >_don > Actually, I'm usually so pleased to see _any_ posts in this group that I don't mind when it gets stuck in a rampid cross-post or some newbie asks how to create those neat little clickable things in MS Windows. Ok, so lets spark up a thread of our own. What are your least and most favorite features about Icon? What would you change? Personally, I'd like to see the &null value act as a general purpose identity for all of the operators except when used as a procedure call. For example: 1 + &null -> 1 1 * &null -> 0 'abc' ++ &null -> 'abc' "foo" || &null -> "foo" [1,2,3] ||| &null -> [1,2,3] &null(1, 2, 3) -> Obscure Runtime Error: 169 I'd probably even extend this to other "operators" such as those that work on lists, tables and sets. Oh, and feel free to crosspost this to alt.babble.ted.nelson :) From icon-group-sender Fri Jun 16 10:51:39 1995 Received: by cheltenham.cs.arizona.edu; Fri, 16 Jun 1995 12:29:08 MST Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 16 Jun 1995 10:51:39 -0800 To: icon-group@cs.arizona.edu From: bobalex@netcom.com (Bob Alexander) Subject: Re: Best and worst features of Icon (was: ICON vs Ted Nelson) Errors-To: icon-group-errors@cs.arizona.edu >From: scott@cs.arizona.edu (Scott E Gilbert) >Personally, I'd like to see the &null value act as a general purpose >identity for all of the operators except when used as a procedure call. For >example: > > 1 + &null -> 1 > 1 * &null -> 0 > 'abc' ++ &null -> 'abc' > "foo" || &null -> "foo" > [1,2,3] ||| &null -> [1,2,3] > &null(1, 2, 3) -> Obscure Runtime Error: 169 > >I'd probably even extend this to other "operators" such as those that work >on lists, tables and sets. Interestingly, the behavior you suggest was present in SNOBOL4, Icon's grandparent. I'd bet the reason for the absense of default behaviors for &null is that those behaviors can be the source of obscure bugs. I know I personally catch lots of errors when I try to add a number to a variable that doesn't exist (i.e. was misspelled) -- usually my first seven errors in any new program! Another argument for no default behaviors: a program is more transparent (in a readability sense) if the expected initial value of a variable is explicitly set -- if it isn't you might have to scan back in a procedure to make sure it didn't have some value left from a previous use. This can bite you for "static" variables, too. On the other hand, since &null is the often-used equivalent of boolean "false", it *does* have a default behavior for that usage. Bottom line: although sometimes I wish for the cuteness of not having to initialize a variable before I use it, I tend to prefer the existing handling of &null. I'm willing to put in the extra line of code (which makes my program more readable), and bear the extra millisecond and few bytes added to my program. What I *do* wish for sometimes, though, is a generic non-null value, to provide symmetry for boolean usage -- something like &true (although using 1 or "true" isn't really all that bad). My biggest Icon wish: better connection with the real world (i.e. interface to C -- this is probably Icon's worst handicap). By the way, the preferred spelling is "Icon", not "ICON" (as pointed out in the FAQ). Bob Alexander bobalex@netcom.com From icon-group-sender Fri Jun 16 14:20:51 1995 Received: by cheltenham.cs.arizona.edu; Fri, 16 Jun 1995 12:29:22 MST Date: Fri, 16 Jun 1995 14:20:51 -0400 (EDT) From: John Kohl X-Sender: kohl@nova To: Scott E Gilbert Cc: icon-group@cs.arizona.edu Subject: Re: ICON vs Ted Nelson In-Reply-To: <3rqsq6$g9s@lectura.CS.Arizona.EDU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@cs.arizona.edu On 15 Jun 1995, Scott E Gilbert wrote: > > Ok, so lets spark up a thread of our own. What are your least and most > favorite features about Icon? What would you change? > > Personally, I'd like to see the &null value act as a general purpose > identity for all of the operators except when used as a procedure call. For > example: > > 1 + &null -> 1 > 1 * &null -> 0 > 'abc' ++ &null -> 'abc' > "foo" || &null -> "foo" > [1,2,3] ||| &null -> [1,2,3] > &null(1, 2, 3) -> Obscure Runtime Error: 169 > > I'd probably even extend this to other "operators" such as those that work > on lists, tables and sets. > I would also appreciate the above feature. I request being able to declare the types of variables for at least a translation time check. This would modestly increase the writing effort for those of us who choose to do the typing. But it would cut down on some lengthier debug time. John Kohl Univ. Maryland, University College From icon-group-sender Fri Jun 16 10:30:07 1995 Received: by cheltenham.cs.arizona.edu; Fri, 16 Jun 1995 12:29:48 MST To: icon-group@cs.arizona.edu Date: 16 Jun 1995 10:30:07 -0700 From: dave@cs.arizona.edu (Dave Schaumann) Message-Id: <3rsf2v$1e@lectura.CS.Arizona.EDU> Organization: University of Arizona CS Department, Tucson AZ Sender: icon-group-request@cs.arizona.edu References: <3rpcmd$ie0@canopus.cc.umanitoba.ca>, <3rqsq6$g9s@lectura.CS.Arizona.EDU> Subject: Language features & behavior of &null (was Re: ICON vs Ted Nelson) Errors-To: icon-group-errors@cs.arizona.edu In article <3rqsq6$g9s@lectura.CS.Arizona.EDU>, Scott E Gilbert wrote: > >Ok, so lets spark up a thread of our own. What are your least and most >favorite features about Icon? What would you change? Mostly what I don't like about Icon is some important (IMHO) things are missing. Most obviously, some general interface to system calls would make Icon much more useful for programming in shell-script situations. Also, it would be nice if Icon had some facility for writing large programs (ie, name space control, inline functions, enumerated types, real booleans, etc). >Personally, I'd like to see the &null value act as a general purpose >identity for all of the operators except when used as a procedure call. I disagree. IMHO, this is one place where Icon got it right. One of my pet peeves is when some obscure default of a language hides an error I've made by leaving something out. If I've forgotton to initialize a variable, I want to know it. -Dave From icon-group-sender Fri Jun 16 18:26:04 1995 Received: by cheltenham.cs.arizona.edu; Fri, 16 Jun 1995 12:29:33 MST To: icon-group@cs.arizona.edu Date: Fri, 16 Jun 1995 18:26:04 +0100 (BST) From: H.Lawson@tees.ac.uk (Hamish Lawson) Message-Id: <1995Jun16.172604.22642@leeds.ac.uk> Organization: University of Teesside Sender: icon-group-request@cs.arizona.edu Subject: Perl v. Icon Errors-To: icon-group-errors@cs.arizona.edu Could someone familiar with both Perl and Icon give me a (preferably reasoned :) comparison of the text-processing abilities of Perl and Icon (I have little need for system-management functions). The sort of tasks I have in mind are building HTML pages, converting files from one markup to another, extracting text out of e-mail messages, and doing global edits to files. -- | Hamish Lawson, School of Computing and Mathematics, | University of Teesside, Middlesbrough, Cleveland, UK, TS1 3BA | Tel: +44 1642 218121 x3611 Email: H.Lawson@tees.ac.uk From icon-group-sender Fri Jun 16 11:42:08 1995 Received: by cheltenham.cs.arizona.edu; Fri, 16 Jun 1995 16:24:48 MST To: icon-group@cs.arizona.edu Date: 16 Jun 1995 11:42:08 -0700 From: scott@cs.arizona.edu (Scott E Gilbert) Message-Id: <3rsja0$2jm@lectura.CS.Arizona.EDU> Organization: University of Arizona CS Department, Tucson AZ Sender: icon-group-request@cs.arizona.edu References: <3rpcmd$ie0@canopus.cc.umanitoba.ca>, <3rqsq6$g9s@lectura.CS.Arizona.EDU>, <3rsf2v$1e@lectura.CS.Arizona.EDU> Subject: Re: Language features & behavior of &null (was Re: ICON vs Ted Nelson) Errors-To: icon-group-errors@cs.arizona.edu Dave Schaumann wrote: >In article <3rqsq6$g9s@lectura.CS.Arizona.EDU>, >Scott E Gilbert wrote: >> >>Ok, so lets spark up a thread of our own. What are your least and most >>favorite features about Icon? What would you change? > >Mostly what I don't like about Icon is some important (IMHO) things >are missing. Most obviously, some general interface to system calls >would make Icon much more useful for programming in shell-script >situations. Also, it would be nice if Icon had some facility for >writing large programs (ie, name space control, inline functions, >enumerated types, real booleans, etc). > Well, I sort of agree. I'd like to see a new top level declaration to go aside "global" and "procedure" that would presumably be called "object", and then some scoping modifiers for inside this such as "private" or "hidden" and "public" or something like that. Carry the OOP stuff far enough, and that would fix any concerns about "large" programs. I'd also like to be able to nest procedure declarations. All of this would make it a completely different language though. As for system calls and what not, I'd like to see a documented and clean interface to things likes pipes and sockets. I'm sure there is some hidden option to open() that will handle it, but I haven't seen it documented anywhere. > >>Personally, I'd like to see the &null value act as a general purpose >>identity for all of the operators except when used as a procedure call. > >I disagree. IMHO, this is one place where Icon got it right. One of >my pet peeves is when some obscure default of a language hides an error >I've made by leaving something out. If I've forgotton to initialize >a variable, I want to know it. > You're one of those people who insists on using "local" inside of every procedure and compiling with the -u option aren't you. :) I personally just try to make every variable local, then you don't need to worry about it. I guess this is just a style issue. I tend to write lots of tiny procedures instead of fewer big ones, and that makes it difficult to lose track of what and where. The one case where this hurts is typos. What I hate is using a language where all of the type information is carried around for you at run time, but you still have to do stuff like: t:= table() S:= set() l:= list() s:= "" before you can build on anything. I mean you might as well go back to declaring the type at the top of the procedure like you do in C or Pascal. From icon-group-sender Sat Jun 17 09:36:13 1995 Received: by cheltenham.cs.arizona.edu; Mon, 19 Jun 1995 09:01:38 MST Date: Sat, 17 Jun 1995 09:36:13 -0500 From: jeffery@runner.jpl.utsa.edu (Clinton L. Jeffery) Message-Id: <9506171436.AA04497@runner.utsa.edu> To: H.Lawson@tees.ac.uk Cc: icon-group@cs.arizona.edu In-Reply-To: <1995Jun16.172604.22642@leeds.ac.uk> (H.Lawson@tees.ac.uk) Subject: Re: Perl v. Icon Content-Length: 833 Errors-To: icon-group-errors@cs.arizona.edu > From: H.Lawson@tees.ac.uk (Hamish Lawson) > Could someone familiar with both Perl and Icon give me a (preferably > reasoned :) comparison of the text-processing abilities of Perl and Icon Perl's strong suit (for text processing; it has other strong suits) are regular-expression-based jobs that manipulate text that is structured fairly simply. Icon's strength comes out in more complex jobs where the patterns to be matched are more complex than regular expressions would handle trivially, and where the computation (in your case, text-processing) calls for complex data structures and/or algorithms. Of course, Icon does quite nicely for simple data structures & algorithms, too... :) The kinds of jobs you described are pretty ideal for Icon; I would write one in Icon and one in Perl, and see which you prefer. From icon-group-sender Sat Jun 17 17:43:19 1995 Received: by cheltenham.cs.arizona.edu; Mon, 19 Jun 1995 09:02:00 MST To: icon-group@cs.arizona.edu Date: Sat, 17 Jun 1995 17:43:19 GMT From: john@nmt.edu (John Shipman) Message-Id: <1995Jun17.174319.29735@nmt.edu> Organization: Zoological Data Processing Sender: icon-group-request@cs.arizona.edu References: <1995Jun16.172604.22642@leeds.ac.uk> Subject: Re: Perl v. Icon Errors-To: icon-group-errors@cs.arizona.edu I've been a heavy Icon user for a year or so now, and I think it's a good choice for text processing applications, especially when you need a good selection of data structures. Let me give you an example of the sort of thing I do all the time in Icon, so you can assess whether your needs are similar. Next week I'll be starting a project to display the ``knowledge base'' of the New Mexico Tech Computer Center staff in two different forms---as typeset copy and as web pages. The input is a list of skills (C++, hardware repair, etc.), structured as a three-level hierarchy (major category, minor category, and skill name), with each skill followed by a list of people who have that skill, and a rating of B for beginner, I for intermediate, and E for expert. This input file is to be processed by two different Icon programs. The first translates the skill list into a fully ruled table using TeX notation. The initials of the people are placed on column headings across the top, and the skills names are the row headings running down the left side. At each cell is the skill level code. The second program will translate the same list into a web structured in this manner: * The first page will be a bullet list, with links pointing to pages for each major skill category (user skills, help desk skills, system programming skills). * The major-category pages are bullet lists pointing to minor-category pages. For example, the user page will have a bullet for programming languages. * Each minor-category page lists each skills (e.g., C++) followed by a list of the experts, the intermediates, and the beginners. Each name on the list is a link to a page with name, schedule and contact info for that person. Icon is really ideal for this sort of small textual database application. Parsing the input file is quite trivial, there's not much to it. Ideally, though, in order to reuse the part of the program that parses the input, I want to build an object that represents the entire knowledge base, and provide methods on that object that cover the repertoire of functions that the two different applications will need. Although Icon is not technically an object-oriented language, I can still get the kind of encapsulation and abstraction that I need. Inside the object, I clearly need a heterogeneous tree that allows me to jump from major category to minor category to skill to person. The Icon concept of generators gives me a foolproof way to allow the caller to visit each child of a parent node, for example, without having to worry about how the tree is structured. I must confess that I don't know much Perl. I have looked at some scripts a few dozen lines long. As far as I can tell, the only reason people put up with the rather ugly and cryptic syntax of Perl is that it's useful for system administration tasks. I'm not a sysadmin; my title is ``Applications Specialist.'' As a further disclaimer, I'm rather manic about good style. I want my programs to be legible, and I find that Icon gives me a very natural expression of the problem. I also find that modifying programs is straightforward. Since I discovered Icon, I have written negligible amounts of C, and nothing in Awk. Most of my work involves transformation of text input files into text output files (although I have done a little work with portable binary encodings in files), and I'd say I'm three times as productive as with C and twice Awk. -- John Shipman (js@cs.nmt.edu) ``Let's go outside and commiserate with nature.'' --Dave Farber From icon-group-sender Sat Jun 17 17:06:58 1995 Received: by cheltenham.cs.arizona.edu; Mon, 19 Jun 1995 09:01:50 MST To: icon-group@cs.arizona.edu Date: Sat, 17 Jun 1995 17:06:58 GMT From: john@nmt.edu (John Shipman) Message-Id: <1995Jun17.170658.29531@nmt.edu> Organization: Zoological Data Processing Sender: icon-group-request@cs.arizona.edu References: <3rpcmd$ie0@canopus.cc.umanitoba.ca>, <3rqsq6$g9s@lectura.CS.Arizona.EDU> Subject: &null as a general-purpose identity Errors-To: icon-group-errors@cs.arizona.edu Scott E Gilbert wrote: +-- | Personally, I'd like to see the &null value act as a general purpose | identity for all of the operators except when used as a procedure call. For | example: | | 1 + &null -> 1 | 1 * &null -> 0 | 'abc' ++ &null -> 'abc' | "foo" || &null -> "foo" | [1,2,3] ||| &null -> [1,2,3] | &null(1, 2, 3) -> Obscure Runtime Error: 169 +-- Only if it's an option, and preferably not the standard option. I catch a lot of bugs with its current behavior. -- John Shipman (js@cs.nmt.edu) ``Let's go outside and commiserate with nature.'' --Dave Farber From icon-group-sender Sun Jun 18 12:34:35 1995 Received: by cheltenham.cs.arizona.edu; Mon, 19 Jun 1995 09:02:19 MST To: icon-group@cs.arizona.edu Date: 18 Jun 1995 12:34:35 GMT From: dcorbo@ix.netcom.com (Dennis Corbo) Message-Id: <3s16gr$env@ixnews3.ix.netcom.com> Organization: Netcom Sender: icon-group-request@cs.arizona.edu Subject: ICON and Data Conversion Errors-To: icon-group-errors@cs.arizona.edu In the last few years, I've worked on several downsizing and data warehouse projects. One of the requirements is always to take mainframe information and convert it into some format that can be loaded into the new system database, usually UNIX based but I suspect I'll be working with NT soon. When I perform this work, I require the delivery of a plain ascii text file. I then use KSH with PERL or AWK to parse the file and create the file(s) for loading. Some of the conversion processing involves creating relationships with several other files or database tables for referential integrity or looking up descriptive data, etc. I am always looking for good tools that can make my work easier and of better quality. I would like to know if ICON is suitable for this type of work. Dennis Corbo From icon-group-sender Sun Jun 18 16:09:07 1995 Received: by cheltenham.cs.arizona.edu; Mon, 19 Jun 1995 09:02:35 MST To: icon-group@cs.arizona.edu Date: 18 Jun 1995 16:09:07 +0100 From: ian@pipex.net (Ian Phillipps) Message-Id: <3s1fij$7r9@pipe.pipex.net> Organization: PIPEX, 216 Science Park, Cambridge, England Sender: icon-group-request@cs.arizona.edu References: <1995Jun16.172604.22642@leeds.ac.uk>, <1995Jun17.174319.29735@nmt.edu> Subject: Re: Perl v. Icon Errors-To: icon-group-errors@cs.arizona.edu In article <1995Jun17.174319.29735@nmt.edu>, John Shipman wrote: >I've been a heavy Icon user for a year or so now, and I think >it's a good choice for text processing applications, especially >when you need a good selection of data structures. OK, I'm a heavy perl programmer (not that heavy for my height, though). A couple of years ago I looked fairly closely at Icon, and elected to remain with Perl. With Perl 4 and earlier, the weak point was, as John implies, data structures, although the split and join operators provided quite convenient workarounds. Judging what I remember of Icon (version 8, I think) and perl 5, here's my assessment of relative strengths: (P=Perl stronger, I=Icon stronger) P Online documentation (Full icon docs are only available as a conventional book) PPP Regular expressions. This is the biggie as far as I'm concerned. The sort of job where you're trying to parse incoming data which has a slightly unknown syntax. By comparison, the Icon method of lots of operators to scan across a string is seriously clunky. (BTW the date I finally gave up on Icon is when I read in the Icon newsletter that Ralph Griswold was never going to put REs into Icon) - List structures I List processing. The list-traversal primitives of Icon are still better that those of Perl. Things like lazy evaluation fall directly out of Icon syntax. ? Syntax. I don't agree that Perl syntax is ugly, at least no more than any other computer language. It's unconventional, certainly, to put "$" before all scalars. But after a very short while you know that "$" means it's a scalar, and is helpful. Icon's use of syntax "looks cleaner" but is, if anything, rather more unconventional. This is another area where Perl 5 has made a difference. P Support. I don't currently subscribe to comp.lang.icon, but you'd be hard put to it to find a friendlier place to ask daft questions than comp.lang.perl.misc (new name..). Oh, and get answers :-). C.l.p postings outnumber c.l.i. postings by around 30 to 1, not that that proves anything. I? Icon has a two-phase interpretation process, which is cumbersome for quick one-shot programs, but a payoff for bigger ones. (I think you can work round this by using "eval", but I don't really remember). I Co-expressions. This is a very powerful paradigm - a generalisation of co-routines - built into the Icon language (although at the time I could only really play on DOS and was greeted with "co-expressions not implemented"). P The full specification of perl and its libraries is available on-line. "You can't search dead trees". >The input is a list of skills (C++, hardware repair, etc.), >structured as a three-level hierarchy (major category, minor >category, and skill name), with each skill followed by a list >of people who have that skill, and a rating of B for beginner, >I for intermediate, and E for expert. Hmm.. I'd give this project around 2-3 days in perl, at the most. [Resists temptation to include perl solution in posting :-)] >applications will need. Although Icon is not technically an >object-oriented language, I can still get the kind of >encapsulation and abstraction that I need. If we were comparing Icon with perl 4, I'd vote for Icon on this. Perl 5 levels this playing field. >to person. The Icon concept of generators gives me a foolproof >way to allow the caller to visit each child of a parent node, for >example, without having to worry about how the tree is >structured. >As a further disclaimer, I'm rather manic about good style. I >want my programs to be legible, and I find that Icon gives me >a very natural expression of the problem. I also find that >modifying programs is straightforward. A danger with any powerful language is that it can be too concise for its own good. While neither Perl nor Icon can compete with APL in this league, it's possible to write exceedingly cryptic programs in each. Or in any programming language, for that matter (see ftp://gatekeeper.dec.com/.8/misc/ioccc/1988/phillipps.c, for instance) It's a programmer's job to explain what's not obvious - the problem is to remember what that is! Generators are nice - if you know what's going on. If not, they can be very puzzling, since the paradigm is unique to Icon. >Since I discovered Icon, I have written negligible amounts of C, >and nothing in Awk. Most of my work involves transformation of Sounds like my experience with Perl :-) >text input files into text output files (although I have done a >little work with portable binary encodings in files), and I'd say >I'm three times as productive as with C and twice Awk. Hmm.. I'd be surprised if awk were only twice as good as C in its domain. For text-bashing, I'd put the C:awk:perl ratio at 1:3-10:8 The awk figure depends heavily on whether you have to work-around the limits in it. Ian From icon-group-sender Sun Jun 18 18:11:42 1995 Received: by cheltenham.cs.arizona.edu; Mon, 19 Jun 1995 09:03:03 MST To: icon-group@cs.arizona.edu Date: Sun, 18 Jun 1995 18:11:42 GMT From: goer@quads.uchicago.edu (Richard L. Goerwitz) Message-Id: Organization: The University of Chicago Sender: icon-group-request@cs.arizona.edu References: <1995Jun16.172604.22642@leeds.ac.uk>, <1995Jun17.174319.29735@nmt.edu>, <3s1fij$7r9@pipe.pipex.net> Reply-To: goer@midway.uchicago.edu Subject: Re: Perl v. Icon Errors-To: icon-group-errors@cs.arizona.edu In article <3s1fij$7r9@pipe.pipex.net>, Ian Phillipps wrote: > >With Perl 4 and earlier, the weak point was, as John implies, data >structures, although the split and join operators provided quite >convenient workarounds. Really, there's no question that Perl has much, much better integra- tion with the OS then Icon. And interfaces exist between it and all the major databases, etc. Perl is also being very actively worked on. As far as I know, development work on Icon has officially ceased, and all we will see are, perhaps, a few additional ports. Refinements to the windowing system will probably go on for a few years, too. >PPP Regular expressions. This is the biggie as far as I'm concerned. > The sort of job where you're trying to parse incoming data which > has a slightly unknown syntax. By comparison, the Icon method > of lots of operators to scan across a string is seriously > clunky. There is truth here. For certain jobs, regexps are much terser and and more expressive than Icon's string scanning. But then, on the other hand, Icon's string scanning is much, much more powerful than regexps. There would have been absolutely no sense in adding reg- exps to the core language definition when they can only deal with a small subset of the grammars scanning can handle. It's just two very different approaches to language design. The bottom line is that Icon is much more flexible, powerful, and ele- gant for certain types of things. Perl is much terser, more lucid, and more convenient for others. >? Syntax. I don't agree that Perl syntax is ugly, at least no more > than any other computer language. What syntax? Perl was specifically designed to feel comfortable to people accustomed to using a mishmash of sed, awk, sh, and C. There has been some attempt at streamlining its grammar(s). But there is, and never will be, any comparison between Icon and Perl along these lines. Icon is just much, much cleaner. >P Support. The Icon community is small and "researchy." There's no comparing it with the Perl community, which is just much larger and more responsive to a larger range of questions and needs. >>The input is a list of skills (C++, hardware repair, etc.), >>structured as a three-level hierarchy (major category, minor >>category, and skill name), with each skill followed by a list >>of people who have that skill, and a rating of B for beginner, >>I for intermediate, and E for expert. > >Hmm.. I'd give this project around 2-3 days in perl, at the most. Bet it would take less time than this. But I don't see how Perl would be any better than Icon here. The question is what language you see as remaining workable over the long haul. Presumably this isn't the last project you'll be doing! -- Richard L. Goerwitz *** goer@midway.uchicago.edu From icon-group-sender Mon Jun 19 00:56:38 1995 Received: by cheltenham.cs.arizona.edu; Mon, 19 Jun 1995 09:03:11 MST To: icon-group@cs.arizona.edu Date: Mon, 19 Jun 1995 00:56:38 GMT From: johnb02@ibm.net (John Burdick) Message-Id: <3s2i52$1mbm@news-s01.ny.us.ibm.net> Sender: icon-group-request@cs.arizona.edu References: <1995Jun16.172604.22642@leeds.ac.uk>, <1995Jun17.174319.29735@nmt.edu>, <3s1fij$7r9@pipe.pipex.net> Subject: Re: Perl v. Icon Errors-To: icon-group-errors@cs.arizona.edu ian@pipex.net (Ian Phillipps) wrote: >Generators are nice - if you know what's going on. If not, they can be >very puzzling, since the paradigm is unique to Icon. I think "unique" is a little strong. Prolog uses backtrack goal seeking in a similar way. Lazy evaluation in Haskell is defined differently, but is similar in some of it's usage. Iterators in Sather are generators. John From icon-group-sender Mon Jun 19 00:23:48 1995 Received: by cheltenham.cs.arizona.edu; Mon, 19 Jun 1995 09:03:18 MST To: icon-group@cs.arizona.edu Date: 19 Jun 1995 00:23:48 GMT From: rahardj@cc.umanitoba.ca (Budi Rahardjo) Message-Id: <3s2g2k$2n4@canopus.cc.umanitoba.ca> Organization: The University of Manitoba Sender: icon-group-request@cs.arizona.edu References: <1995Jun17.174319.29735@nmt.edu>, <3s1fij$7r9@pipe.pipex.net>, Subject: Re: Perl v. Icon Errors-To: icon-group-errors@cs.arizona.edu At this time, you cannot generate an executable with perl. I would love to do "gcc -o simulator *.o -lperl" (I know it's comming ...) I've not worked with Windows and Mac versions of Icon, but I guess it is nicer than perl for Windows (DOS) and Mac. Having said that, it's easier for me to write a perl script than writing an Icon program. Dunno why, maybe perl is more UNIXy :-) -- budi, JAPH -- Budi Rahardjo #include Unix Support/Administrator - Computer Services - University of Manitoba From icon-group-sender Mon Jun 19 00:20:18 1995 Received: by cheltenham.cs.arizona.edu; Mon, 19 Jun 1995 09:03:44 MST To: icon-group@cs.arizona.edu Date: 19 Jun 1995 00:20:18 GMT From: berniegs@ix.netcom.com (Bernie Schneider) Message-Id: <3s2fs2$3e2@ixnews6.ix.netcom.com> Organization: Netcom Sender: icon-group-request@cs.arizona.edu References: <3s16gr$env@ixnews3.ix.netcom.com> Subject: Re: ICON and Data Conversion Errors-To: icon-group-errors@cs.arizona.edu In <3s16gr$env@ixnews3.ix.netcom.com> dcorbo@ix.netcom.com (Dennis Corbo) writes: > >In the last few years, I've worked on several downsizing and data >warehouse projects. One of the requirements is always to take mainframe >information and convert it into some format that can be loaded into the >new system database, usually UNIX based but I suspect I'll be working >with NT soon. When I perform this work, I require the delivery of a >plain ascii text file. I then use KSH with PERL or AWK to parse the >file and create the file(s) for loading. Some of the conversion >processing involves creating relationships with several other files or >database tables for referential integrity or looking up descriptive >data, etc. I am always looking for good tools that can make my work >easier and of better quality. I would like to know if ICON is suitable >for this type of work. > >Dennis Corbo ICON is certainly suitable for this type of work, but even though I have ICON available for the extensive amounts of data conversion that I must frequently perform, I was surprised to discover that AWK seems to be the language that I most frequently choose for most of these tasks. It's nothing against ICON. I still use it a lot, but it just seems like AWK has about the right combination of simplicity, power, and ease of programming for doing data conversions. I understand that AWK was designed with such tasks in mind. I find that such functions as split, (g)sub, and printf, plus the regular expressions are indispensible most of the times I have to convert data, and none of them are available in ICON directly, although suitable substitutes can be found or developed for them. Incidently I also use PERL, REXX, and occasionally PYTHON, for various utility tasks, but for the frequent one-shot data conversions, that I seem to always be encountering, I just naturally seem to gravitate to AWK most of the time. I guess it's just a better fit to that type of problem. -- ------------------------------------------------------------ Bernie Schneider: | The villain who twirls his | mustache is easy to spot. Those berniegs@ix.netcom.com | who cloak themselves in good hrrd66a@prodigy.com | deeds are well camouflaged. | Capt. Jean Luc Picard From icon-group-sender Mon Jun 19 11:39:28 1995 Received: by cheltenham.cs.arizona.edu; Mon, 19 Jun 1995 12:26:33 MST Date: Mon, 19 Jun 1995 11:39:28 -0600 (CST) From: Chris Tenaglia | 456-8765 Subject: Re: ICON and Data Conversion To: dcorbo@ix.netcom.com Cc: icon-group@cs.arizona.edu Message-Id: <01HRW05Y280I8WWUVE@mis.mcw.edu> Organization: Medical College of Wisconsin (Milwaukee, WI) X-Vms-To: IN%"dcorbo@ix.netcom.com" X-Vms-Cc: IN%"icon-group@cs.arizona.edu" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Errors-To: icon-group-errors@cs.arizona.edu Exactly what I use it for. There's a ton of tools available like Perl, Icon, and AWK. One seems to pick one and use it like a swiss army knife. I use icon as my preferred tool. I've used it for reconciling employee records against the password file to make sure only current employees have accounts. I've made data viewers for cobol programmers. They supply a cobol FD (file def) section, and a data file name and my viewer shows how the data elements fit in the field. Good for checking alignments, empty fields, and ranges. I've written mailing label generators, and printer filters too. Chris Tenaglia (System Manager) | "The past explained, Medical College of Wisconsin | the future foretold, 8701 W. Watertown Plank Rd. | the present largely appologized for." Milwaukee, WI 53226 | Organon to The Doctor (414)456-8765 | tenaglia@mis.mcw.edu > From: IN%"dcorbo@ix.netcom.com" 19-JUN-1995 11:14:39.26 > To: IN%"icon-group@cs.arizona.edu" > Subj: ICON and Data Conversion > In the last few years, I've worked on several downsizing and data > warehouse projects. One of the requirements is always to take mainframe > information and convert it into some format that can be loaded into the > new system database, usually UNIX based but I suspect I'll be working > with NT soon. When I perform this work, I require the delivery of a > plain ascii text file. I then use KSH with PERL or AWK to parse the > file and create the file(s) for loading. Some of the conversion > processing involves creating relationships with several other files or > database tables for referential integrity or looking up descriptive > data, etc. I am always looking for good tools that can make my work > easier and of better quality. I would like to know if ICON is suitable > for this type of work. > Dennis Corbo From icon-group-sender Mon Jun 19 18:09:00 1995 Received: by cheltenham.cs.arizona.edu; Tue, 20 Jun 1995 13:23:49 MST Message-Id: <9506191810.AA27336@ns1.computek.net> Mime-Version: 1.0 Content-Length: 2659 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 19 Jun 95 18:09 CDT From: gep2@computek.net Subject: Re: ICON and Data Conversion To: icon-group@cs.arizona.edu X-Mailer: SPRY Mail Version: 04.00.06.14 Errors-To: icon-group-errors@cs.arizona.edu >>....One of the requirements is always to take mainframe information and convert it into some format that can be loaded into the new system database, usually UNIX based but I suspect I'll be working with NT soon. When I perform this work, I require the delivery of a plain ascii text file. I then use KSH with PERL or AWK to parse the file and create the file(s) for loading. Some of the conversion processing involves creating relationships with several other files or database tables for referential integrity or looking up descriptive data, etc. I am always looking for good tools that can make my work easier and of better quality. I would like to know if ICON is suitable for this type of work. >ICON is certainly suitable for this type of work, but even though I have ICON available for the extensive amounts of data conversion that I must frequently perform, I was surprised to discover that AWK seems to be the language that I most frequently choose for most of these tasks. I think that while you gravitate back to AWK (ugh) that's where I would gravitate back to SNOBOL4+... but I think S4+ is far superior to AWK/Perl, has the concise and elegant pattern description (almost as concise, and FAR more powerful, than REs). >It's nothing against ICON. I still use it a lot, but it just seems like AWK has about the right combination of simplicity, power, and ease of programming for doing data conversions. I understand that AWK was designed with such tasks in mind. AWK and Perl are basically "Poor Man's SNOBOLs", a logistical substitute suitable for implementation on a "tiny machine" that was too small to implement a more sophisticated language like SNOBOL4. It's certainly understandable that they would be more inclined to implement a simpler language than S4... there have only been a handful of truly complete, totally new implementations of S4 ever written. (Nearly all of them have been ports of the SIL macro-based implementation). >I find that such functions as split, (g)sub, and printf, plus the regular expressions are indispensible most of the times I have to convert data, I consider REs a miserably poor substitute for SNOBOL4 patterns, a throwback to UNIX's teletype origins where every keystroke required a punch on a paper tape or a character strike on a 10cps teleprinter. Nowadays that we all work on video displays and with orders of magnitude more processing power, sticking with something as primitive as REs is simply pathetic, as out-of-date as just echoing a backslash or something for each press of the backspace key. Gordon Peterson http://www.computek.net/public/gep2/ From icon-group-sender Mon Jun 19 18:15:00 1995 Received: by cheltenham.cs.arizona.edu; Tue, 20 Jun 1995 13:24:02 MST Message-Id: <9506191815.AA27536@ns1.computek.net> Mime-Version: 1.0 Content-Length: 886 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 19 Jun 95 18:15 CDT From: gep2@computek.net Subject: Re: Perl v. Icon To: icon-group@cs.arizona.edu X-Mailer: SPRY Mail Version: 04.00.06.14 Errors-To: icon-group-errors@cs.arizona.edu >PPP Regular expressions. This is the biggie as far as I'm concerned. The sort of job where you're trying to parse incoming data which has a slightly unknown syntax. By comparison, the Icon method of lots of operators to scan across a string is seriously clunky. Personally, I think that SNOBOL4 patterns are much nicer and easier to use than ICON string scanning for the kinds of things I do, too. >(BTW the date I finally gave up on Icon is when I read in the Icon newsletter that Ralph Griswold was never going to put REs into Icon) This one is hysterical... like saying that you won't buy a car until they start to attach a bridle on the hood, so you can tie your car to a hitching post after parking it. :-) Proof, if any were necessary, as to just how hard old habits die, no matter how ludicrous they are. Gordon Peterson http://www.computek.net/public/gep2/ From icon-group-sender Mon Jun 19 13:22:56 1995 Received: by cheltenham.cs.arizona.edu; Tue, 20 Jun 1995 13:23:37 MST Message-Id: Date: 19 Jun 1995 13:20:06 U From: "Michael Shafto" Subject: Re: ICON and Data Conversio To: " 456-8765 Chris Tenaglia " , dcorbo@ix.netcom.com Cc: icon-group@cs.arizona.edu X-Mailer: Mail*Link SMTP-QM 3.0.2 Errors-To: icon-group-errors@cs.arizona.edu Reply to: RE>>ICON and Data Conversion >From: 456-8765 Chris Tenaglia > >Exactly what I use it for. There's a ton of tools available >like Perl, Icon, and AWK. One seems to pick one and use it >like a swiss army knife. I use icon as my preferred tool. > ... I would just add that the main reason I like the Icon Swiss Army knife is that I can move the same source code from DOS to Mac to Windows -- I need to be able to work on all three platforms. The cross- platform source compatibility, in addition to the data structures supported and the fact that Icon is a real programming language, makes it the knife of choice. Mike From icon-group-sender Tue Jun 20 14:53:08 1995 Received: by cheltenham.cs.arizona.edu; Tue, 20 Jun 1995 16:39:48 MST Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 20 Jun 1995 14:53:08 -0700 To: icon-group@cs.arizona.edu From: bobalex@netcom.com (Bob Alexander) Subject: Re: Perl v. Icon Errors-To: icon-group-errors@cs.arizona.edu For those of you Perl fans who won't touch Icon because it doesn't have regular expressions, here's a bulletin: There is a full implementation of Perl regular expressions in the Icon program library (procs/regexp.icn). I am the author of that procedure library -- however, I can count on half of the fingers on one hand the number of times that I've used it. I much prefer Icon string scanning, even though it's not as terse. The regular expression stuff was lots of fun to write in Icon. Perl fans: try writing Icon's string scanning in Perl. Even if you can do it, I'd bet it won't be much fun :-) Bob Alexander bobalex@netcom.com From icon-group-sender Wed Jun 21 06:18:53 1995 Received: by cheltenham.cs.arizona.edu; Thu, 22 Jun 1995 08:58:40 MST Date: Wed, 21 Jun 1995 06:18:53 -0600 (CST) From: Chris Tenaglia | 456-8765 Subject: Re: Perl vs. Icon To: icon-group@cs.arizona.edu Message-Id: <01HRYHNUKD4I8WW0U0@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 Errors-To: icon-group-errors@cs.arizona.edu I went to a perl session at a Decus symposium, and I could see that it is related to icon (like pascal is related to ada). But I thought the subtitle of the session was interesting, Perl, the swiss army chainsaw, (of unix programming languages). ;-) Chris Tenaglia (System Manager) | "The past explained, Medical College of Wisconsin | the future foretold, 8701 W. Watertown Plank Rd. | the present largely appologized for." Milwaukee, WI 53226 | Organon to The Doctor (414)456-8765 | cdt@post.its.mcw.edu From icon-group-sender Wed Jun 21 18:22:45 1995 Received: by cheltenham.cs.arizona.edu; Thu, 22 Jun 1995 08:59:31 MST To: icon-group@cs.arizona.edu Date: Wed, 21 Jun 95 18:22:45 GMT From: Stephen Harborne Message-Id: <803758965snz@cauchy.demon.co.uk> Organization: Myorganisation Sender: icon-group-request@cs.arizona.edu Reply-To: Stephen@cauchy.demon.co.uk Subject: Context Switching for Silicon Graphics Errors-To: icon-group-errors@cs.arizona.edu I am trying to get context switching sorted out under Silicon Graphics IRIX V5 operating system. The code presented under idis4d configuration, under Icon V9, is not Application Binary Interface (ABI) compatible and after conversion (the compiler does not like it one bit) nothing works, other than core dumps. Does anyone out there use Icon on SGI boxes with IRIX? I make much use of co-expressions so none of these modules work. I would be interested if anyone has any pointers (C pun intended) or suggestions to help me track down the problem. Grateful for input Steve -- Stephen Harborne Science is only a theory From icon-group-sender Wed Jun 21 14:00:48 1995 Received: by cheltenham.cs.arizona.edu; Thu, 22 Jun 1995 08:58:58 MST Date: Wed, 21 Jun 1995 14:00:48 +0300 (WET) From: Ehud Lamm To: Bob Alexander Cc: icon-group@cs.arizona.edu Subject: Re: Perl v. Icon In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@cs.arizona.edu On Tue, 20 Jun 1995, Bob Alexander wrote: > For those of you Perl fans who won't touch Icon because it doesn't have > regular expressions, here's a bulletin: > > There is a full implementation of Perl regular expressions in the Icon > program library (procs/regexp.icn). > > I am the author of that procedure library -- however, I can count on half > of the fingers on one hand the number of times that I've used it. I much > prefer Icon string scanning, even though it's not as terse. > This proves that if you master Icon well enough to program REs in it, you don't really need them, and can use Icon's scanning instead. No doubt a mjor reason in choosing which method to use is which method you know better. :-) An interesting question is what takes longer to learn: Perl's RE or Icon's string scanning. I am not sure there's an answer: it all depends on what program you are trying to write. Some are easier in Perl and some in Icon. Another question is which method is easier to read after written. Icon's way is clearer - but it doesn't force locallity. By this I mean that a single scan (for example looking for a sentence with a certain structure) can be broken into many procedures and span mulitple lines. Usually with a RE you have it all in one place. On the other hand we can learn the great value of one liners from APL... Ehud Lamm From icon-group-sender Wed Jun 21 13:53:39 1995 Received: by cheltenham.cs.arizona.edu; Thu, 22 Jun 1995 08:58:24 MST Date: Wed, 21 Jun 1995 13:53:39 +0300 (WET) From: Ehud Lamm To: gep2@computek.net Cc: icon-group@cs.arizona.edu Subject: Re: ICON and Data Conversion In-Reply-To: <9506191810.AA27336@ns1.computek.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@cs.arizona.edu A question comes to mind regarding what notations are easy for people to use. From my experience it takes people time to grasp RE, but this time is spent is CS classes. Snobol patterns also take time to learn, and I think even more time that RE - but no one really has to learn them in school. The Icon method is superior in that it offers much more than just string scanning - it gives you a whole new flow control mechanism, that can be used for other purposes, and that is integrated in the language. On the other hand it too take time to learn, and seems less relevant to string scanning that REs and S4 patterns. So we have: REs - known and semi-powerful (and you can add all kinds of extensions...) S4 - powerful, take time to learn, but seems closer to REs Icon - Great idea! But takes getting used to the concept. Since I think S4 doesn't stand a chance in the future. And I don't want to make a flame war on this - if you want to say I am wrong, I'd be happy to learn why. So, since S4 is a dying language we can choose between REs which suit people who have to get the job done, and who know REs from school, from GREP etc. , and Icon's wondeful way of doing things which is still used only by the elite... :-) If you have the time and want to invest it in learning a powerful tool learn Icon, if you just need a quick hack I am sure Perl, AWK are much easier to use. Ehud Lamm mslamm@pluto.mscc.huji.ac.il From icon-group-sender Wed Jun 21 09:56:00 1995 Received: by cheltenham.cs.arizona.edu; Thu, 22 Jun 1995 08:59:09 MST Message-Id: <9506210956.AA11846@ns1.computek.net> Mime-Version: 1.0 Content-Length: 5240 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 21 Jun 95 09:56 CDT From: gep2@computek.net Subject: Re: ICON and Data Conversion To: icon-group@cs.arizona.edu X-Mailer: SPRY Mail Version: 04.00.06.14 Errors-To: icon-group-errors@cs.arizona.edu >A question comes to mind regarding what notations are easy for people to use. In fact, I think REs are more cryptic and less intuitive than S4 patterns are (at least, after one gets past "?" and maybe "*"). >From my experience it takes people time to grasp RE, but this time is spent is CS classes. Snobol patterns also take time to learn, and I think even more time that RE - but no one really has to learn them in school. The Icon method is superior in that it offers much more than just string scanning - it gives you a whole new flow control mechanism, that can be used for other purposes, and that is integrated in the language. I agree completely that the Icon string scanning paradigm is more powerful, but I personally find the Icon paradigm as more complicated than SNOBOL4 for the more commonly needed situations. I just think S4 is simpler and easier to use. (There are also other especially neat and extremely powerful features in SNOBOL4 that Icon simply doesn't have, such as the EVAL() and CODE() functions.) In fact, both languages have their uses... I have (and use) both of them, although find that I use SNOBOL4+ at least an order of magnitude more often than I use Icon. Not that I intend that as a criticism of Icon... in general, ever since I've been a struggling student at the University I've been very impressed with SNOBOL4, and now with Icon... I sincerely hope to someday meet Ralph Griswold in person (I've already had the pleasure of meeting his wife Madge on the occasion of an Icon talk she gave to a PC Users' Group there). I have a great deal of professional respect for Professor Griswold, who has clearly contributed SO much to all of us in the computing profession. >So we have: REs - known and semi-powerful (and you can add all kinds of extensions...) Fine, but the more extensions you add the further it gets from being what people recognize as "regular expressions". >S4 - powerful, take time to learn, but seems closer to REs I don't think that being "closer to REs" is any kind of a virtue. I think that SNOBOL4's patterns are fine as they are, a particularly elegant and concise and intuitive way of expressing how a string is to be parsed. If there is anything which I find inconvenient there, it's matching up the corresponding parentheses... although a good Brief macro (I would suppose) could fix that problem. >Icon - Great idea! But takes getting used to the concept. You could, of course, program Icon in much the way you'd program in primitive languages like C or Pascal. But to do so is to lose much of its power and expressivity. >Since I think S4 doesn't stand a chance in the future. And I don't want to make a flame war on this - if you want to say I am wrong, I'd be happy to learn why. SNOBOL4 has NEVER really been a mainstream language... it's always been a language used mostly by the people "in the know", with a dedicated (one might almost say a fanatical) following. The wisdom of having written the SIL implementation (and subsequently the Macro SPITBOL implementation, in turn) in a machine-independent way, combined with a language design and implementation which adapts to most any kind of underlying processor and operating system architecture, has ensured that there have been (and will be) people around who will be willing to port the language to new machines and operating environments as they are released. And now, with the SIL implementation (at least) having been translated to C, that porting process has become even more simple than it has been in the past, ensuring the long-term survival of SNOBOL4. >So, since S4 is a dying language I don't see it as a "dying language", although I'd agree that I don't expect it to ever attain the prominence of C++ or something. Something like Algol (which USED to be very widely used, particularly in Europe, for example) is much more curiously a "dying language", probably since it has less of an intrinsic advantage over C or other competitor languages. Since SNOBOL4 is _so_ unique and its features are NOT duplicated in any other language (Icon probably comes the closest), I don't see any real risk of SNOBOL4 disappearing completely. Obviously however it IS important that those of us who DO know and use the language make other newbies aware of it, through things like these newsgroups, or the links I have on my Web homepage (see the URL below in my signature). >we can choose between REs which suit people who have to get the job done, and who know REs from school, from GREP etc. , and Icon's wonderful way of doing things which is still used only by the elite... :-) Again, a classic example of "start from an invalid premise, and reach an invalid conclusion". :-) >If you have the time and want to invest it in learning a powerful tool learn Icon, if you just need a quick hack I am sure Perl, AWK are much easier to use. Perl and AWK are LESS powerful and (for most things) LESS easy to use than SNOBOL4 is. You've not given any convincing argument of ANY reason why any thinking person would and should use Perl or AWK in preference to something like SNOBOL4. Gordon Peterson http://www.computek.net/public/gep2/ From icon-group-sender Sat Jul 8 10:54:22 1995 Received: by cheltenham.cs.arizona.edu; Sat, 8 Jul 1995 10:55:35 MST Date: Sat, 8 Jul 1995 10:54:22 MST From: "Gregg Townsend" Message-Id: <199507081754.AA06696@cheltenham.cs.arizona.edu> To: icon-group Subject: Icon-group logjam Errors-To: icon-group-errors@cs.arizona.edu Due to a mixup on our end, recent Icon-group mail has been accumulating since June 22 without being forwarded to the list. I'm going to send the backlog now (about a dozen messages), and then things should return to normal. From icon-group-sender Thu Jun 22 22:06:54 1995 Received: by cheltenham.cs.arizona.edu; Sat, 8 Jul 1995 10:56:46 MST Date: Thu, 22 Jun 1995 22:06:54 +0300 (WET) From: Ehud Lamm To: gep2@computek.net Cc: icon-group@cs.arizona.edu Subject: Re: ICON and Data Conversion In-Reply-To: <9506210956.AA11846@ns1.computek.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@cs.arizona.edu From your reply (saying I gave no evidence that Perl is better than Icon) I must conclude that I wasn't clear :-). I am not saying Perl or AWK are better, only that it takes less time to learn how to use them (in a basic way), since most programs know that basics of regular expressions from school. I must admit that I haven't used S4, just read the book and tried some simple examples. You may be right that we should use this group to intorduce new people to these languages. I suppose that a small regualr posting on S4 can be the right thing to do. Ehud Lamm mslamm@pluto.mscc.huji.ac.il From icon-group-sender Thu Jun 22 19:30:00 1995 Received: by cheltenham.cs.arizona.edu; Sat, 8 Jul 1995 10:57:31 MST Message-Id: <9506221930.AA10945@ns1.computek.net> Mime-Version: 1.0 Content-Length: 2594 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 22 Jun 95 19:30 CDT From: gep2@computek.net Subject: Re: ICON and Data Conversion To: icon-group@cs.arizona.edu X-Mailer: SPRY Mail Version: 04.00.06.14 Errors-To: icon-group-errors@cs.arizona.edu >From your reply (saying I gave no evidence that Perl is better than Icon) I must conclude that I wasn't clear :-). I am not saying Perl or AWK are better, only that it takes less time to learn how to use them (in a basic way), The learning of how to use SNOBOL4 "in a basic way" can be taught in less than five or ten minutes. Here is a basic SNOBOL4 program template: A LINE = INPUT :F(END) B LINE pattern = replacement :S(B) OUTPUT = LINE :(A) END The program will read a text file and replace the first occurrence on each line of the given pattern with the given replacement. For example, if you use a pattern of "Mrs." and replacement of "Ms.", you'll get the replacement indicated. Admittedly, there are some more specialized tools that can do this trivial job almost as well, but with SNOBOL4 you're not limited to only those simple jobs. For example, an only slightly more complex pattern and replacement would be: pattern: SPAN("0123456789.") . N replacement: N + 1 That would take the first numeric substring (including real numbers) in each record, and increment the numeric value by one. >since most programs know that basics of regular expressions from school. There's no reason why they shouldn't be taught SNOBOL4 patterns in school, instead of the far more limited REs. >I must admit that I haven't used S4, just read the book and tried some simple examples. I've found that, without exception, the people I know who swear by AWK and Perl are people who haven't really bothered to learn SNOBOL4. On the other hand, I don't know ANYBODY who's learned SNOBOL4 who has any interest whatsoever in either AWK or Perl. Why would a person want to switch to a more limited, less powerful tool? >You may be right that we should use this group to intorduce new people to these languages. Well, I don't see much point in "introducing" Perl or AWK. There are enough people who know, and enough books about, those already. But I don't mind discussing SNOBOL4 here, since (after all) so many of the design concepts underlying Icon are those that derive from SNOBOL4. >I suppose that a small regualr posting on S4 can be the right thing to do. You might want to take a look at the information on my Web page about SNOBOL4, and it also has a link for downloading the freeware Vanilla SNOBOL4. That package comes with a very well-written (almost 150 pages) tutorial and user's guide, it's an excellent way to learn the language. Gordon Peterson http://www.computek.net/public/gep2/ From icon-group-sender Mon Jun 26 17:08:50 1995 Received: by cheltenham.cs.arizona.edu; Sat, 8 Jul 1995 10:57:50 MST Subject: problem building icon 9.0 under unixware 2.01 To: pacbell!cs.arizona.edu!icon-group@pacbell.com Date: Mon, 26 Jun 1995 17:08:50 -0700 (PDT) From: "Mike LeRoy" Cc: mike@gw.PacBell.COM (Mike LeRoy) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Message-Id: <2fef4c130.6ae7@mslbrb> Content-Transfer-Encoding: 7bit Content-Length: 4437 Errors-To: icon-group-errors@cs.arizona.edu hi, I've been trying to build icon v9 under UnixWare 2.01 for a while and have come up with a probem in the data.r and other *.r. with the D_Integer, D_Null construction. Here's the sample chunks in 1 piece to cause the error: - - - - cut here - - - - - - - - - /* * try to show problem under UnixWare 2.01 * */ /* * from typdefs.h */ #if IntBits != WordBits typedef long int word; typedef unsigned long int uword; #else /* IntBits != WordBits */ typedef int word; #ifdef CDC_VXVE typedef uword; #else /* CDC_VXVE */ typedef unsigned int uword; #endif /* CDC_VXVE */ #endif /* IntBits != WordBits */ typedef int (*fptr)(); typedef struct descrip *dptr; typedef word C_integer; /* * from rstructs.h */ struct descrip { /* descriptor */ word dword; /* type field */ union { word integr; /* integer value */ char *sptr; /* pointer to character string */ union block *bptr; /* pointer to a block */ dptr descptr; /* pointer to a descriptor */ } vword; }; /* * from config.h */ #ifndef WordBits #define WordBits 32 #endif /* WordBits */ #ifndef IntBits #define IntBits WordBits #endif /* IntBits */ /* * from cpuconf.h */ #if WordBits == 64 #ifndef MinLong #define MinLong ((long int)0x8000000000000000) /* smallest long integer */ #endif #ifndef MaxLong #define MaxLong ((long int)0x7fffffffffffffff) /* largest long integer */ #endif #define MaxStrLen 017777777777L /* maximum string length */ #ifndef MaxNegInt #define MaxNegInt "-9223372036854775808" #endif #ifndef F_Nqual #define F_Nqual 0x8000000000000000 /* set if NOT string qualifier */ #endif /* F_Nqual */ #ifndef F_Var #define F_Var 0x4000000000000000 /* set if variable */ #endif /* F_Var */ #ifndef F_Ptr #define F_Ptr 0x1000000000000000 /* set if value field is pointer */ #endif /* F_Ptr */ #ifndef F_Typecode #define F_Typecode 0x2000000000000000 /* set if dword includes type code */ #endif /* F_Typecode */ #endif /* WordBits == 64 */ /* * 32-bit words. */ #if WordBits == 32 #define MaxLong ((long int)017777777777L) /* largest long integer */ #define MinLong ((long int)020000000000L) /* smallest long integer */ #define MaxNegInt "-2147483648" #define MaxStrLen 0777777777 /* maximum string length */ #define F_Nqual 0x80000000 /* set if NOT string qualifier */ #define F_Var 0x40000000 /* set if variable */ #define F_Ptr 0x10000000 /* set if value field is pointer */ #define F_Typecode 0x20000000 /* set if dword includes type code */ #endif /* WordBits == 32 */ /* * from rmacros.h */ #define T_Null 0 /* null value */ #define T_Integer 1 /* integer */ #define D_Typecode (F_Nqual | F_Typecode) #define D_Null (T_Null | D_Typecode) #define D_Integer (T_Integer | D_Typecode) struct descrip kywd_err = {D_Integer}; /* &error */ struct descrip kywd_pos = {D_Integer}; /* &pos */ struct descrip x_x = {T_Integer}; struct descrip y_y = {D_Typecode}; struct descrip z_z = {F_Nqual}; struct descrip w_z = {F_Typecode}; - - - - cut here - - - - - - - - - the output of cc: UX:acomp: WARNING: "prob.c", line 122: initializer does not fit: 0xa0000001 UX:acomp: WARNING: "prob.c", line 123: initializer does not fit: 0xa0000001 UX:acomp: WARNING: "prob.c", line 126: initializer does not fit: 0xa0000000 UX:acomp: WARNING: "prob.c", line 127: initializer does not fit: 0x80000000 Undefined first referenced symbol in file main /usr/ccs/lib/crt1.o UX:ld: ERROR: a.out: fatal error: Symbol referencing errors. No output written to a.out - - - - - the solution I think is to change typedef int word -> typedef unsigned word What other problems have I caused by doing this? mike -- Mike LeRoy 4909 Sea Wolf Drive Santa Rosa, CA 95409-3526 pacbell.com!mslbrb!mike voice (707) 538-7832 From icon-group-sender Wed Jun 28 21:26:16 1995 Received: by cheltenham.cs.arizona.edu; Sat, 8 Jul 1995 10:58:06 MST Date: Wed, 28 Jun 95 21:26:16 CDT From: yak@comm.mot.com (Yarko Tymciurak) Message-Id: <9506290226.AA11305@platov8> To: icon-group@cs.arizona.edu Subject: Mac Icon Test Errors-To: icon-group-errors@cs.arizona.edu A little while ago, I noted the Mac version of Icon crashes consistently w/ any 8-bit input. Here's a cyrillic input file that does it (any cyrillic input will crash that Icon). (Sorry for posting this - I lost the name of who wanted it) Yarko Tymciurak. begin 640 Cyrillic (Crashes Mac-Icon) M5$535 T@BHBZ@@T@BX*G@@T@D*>"C84-((Z$A9& #2"$C:>/D(Z/A9*0CH*1 MG(H-()6%D)&.C0T@CXZ+DH""@ T@C(B*CHN NH(-()>.D(V.@8B+G T@DH60 MC8Z/IXN<#2"&B)*.C(B0#2"G@H"-CI20@(V*IX*1G(H-((N3EIR*#2"5@)"* MIX(-((N3@X"-D9R*#2"$CHV%EIR*#2"*A9"7#2"'@(^.D*>&AI\-().&@XZ0 MCH0-((R3BH"7A8*%#2"$D(Z#CIZ!B)<-((..D(NG@HJ #2"1BHR(#2"!CH.. .A).5IX(-((J.C8Z2CH^$ end From icon-group-sender Sun Jul 2 20:51:12 1995 Received: by cheltenham.cs.arizona.edu; Sat, 8 Jul 1995 10:58:27 MST To: icon-group@cs.arizona.edu Date: Sun, 2 Jul 1995 20:51:12 GMT From: idealord@dorsai.dorsai.org (Jeff Harrington) Message-Id: Organization: The Dorsai Embassy - New York Sender: icon-group-request@cs.arizona.edu Subject: Icon V9.0 X Windows Question Errors-To: icon-group-errors@cs.arizona.edu This is going to show my deep deep ignorance of X-Windows, but I'm so proud to get it running on my Pentium that I could care less! I've just compiled kaleid.icn and now I can't get Fvwm nor the other X-Windows desktops to recognize it. I tried placing it in the apps-default directory but still no cigar. How do I run these cool new Icon things? of course, just typing in the name from a shell doesn't do it (although I did try that). -- Jeff Harrington idealord@dorsai.dorsai.org -- (*) Most Beautiful Site on the Net: Net in Arcadia http://www.parnasse.com/(*) (*) Elsie Russell's Pics! Jeff Harrington's Music ->>>> Art + The Bizarre (*) (*) Jeff's Musical WWW Site->>>> http://www.parnasse.com/jeff.htm (*) (*) IdEAL ORDER Psychic TV - All Days But Thursdays(ABC) on CBS Since 1984 (*) From icon-group-sender Mon Jul 3 21:56:23 1995 Received: by cheltenham.cs.arizona.edu; Sat, 8 Jul 1995 10:58:39 MST To: icon-group@cs.arizona.edu Date: 3 Jul 1995 21:56:23 GMT From: eds@ns2.icon.net (David Shaffer) Message-Id: <3t9p27$ic8@news.icon.net> Organization: (ICON) InterConnect Online, Inc. Sender: icon-group-request@cs.arizona.edu References: Subject: Re: Icon V9.0 X Windows Question Errors-To: icon-group-errors@cs.arizona.edu you might try another news group... not many users here are using xwin... i use it but am not an expert on it. make sure your libs are all there and in the correct place though... thats about all i can offer... ive never messed w/ kaleid.icn. good luck. : I've just compiled kaleid.icn and now I can't get Fvwm nor the other : X-Windows desktops to recognize it. I tried placing it in the : apps-default directory but still no cigar. : How do I run these cool new Icon things? of course, just typing in the name : from a shell doesn't do it (although I did try that). From icon-group-sender Tue Jul 4 14:50:43 1995 Received: by cheltenham.cs.arizona.edu; Sat, 8 Jul 1995 10:58:54 MST To: icon-group@cs.arizona.edu Date: Tue, 4 Jul 1995 14:50:43 GMT From: bruce@liverpool.ac.uk Message-Id: Organization: IASC, University of Liverpool Sender: icon-group-request@cs.arizona.edu References: Subject: Re: Icon V9.0 X Windows Question Errors-To: icon-group-errors@cs.arizona.edu >>>>> "Jeff" == Jeff Harrington writes: > This is going to show my deep deep ignorance of X-Windows, but I'm > so proud to get it running on my Pentium that I could care less! > I've just compiled kaleid.icn and now I can't get Fvwm nor the other > X-Windows desktops to recognize it. I tried placing it in the > apps-default directory but still no cigar. > How do I run these cool new Icon things? of course, just typing in > the name from a shell doesn't do it (although I did try that). You should simply run it from a shell, I'm afraid. fvwm and other managers have fancier ways of doing it, but essentially all they do is execute the program. Do any of your other X programs work? If not, then perhaps you've got DISPLAY set incorrectly, or something similarly silly. Otherwise it looks as though there's something wrong with your icon installation. -- Bruce Institute of Advanced Scientific Computation bruce@liverpool.ac.uk University of Liverpool http://supr.scm.liv.ac.uk/~bruce/ From icon-group-sender Wed Jul 5 12:03:10 1995 Received: by cheltenham.cs.arizona.edu; Sat, 8 Jul 1995 10:59:11 MST To: icon-group@cs.arizona.edu Date: Wed, 5 Jul 1995 12:03:10 GMT From: idealord@dorsai.dorsai.org (Jeff Harrington) Message-Id: Organization: The Dorsai Embassy - New York Sender: icon-group-request@cs.arizona.edu References: , Subject: Re: Icon V9.0 X Windows Question Errors-To: icon-group-errors@cs.arizona.edu bruce@liverpool.ac.uk wrote: : >>>>> "Jeff" == Jeff Harrington writes: : > This is going to show my deep deep ignorance of X-Windows, but I'm : > so proud to get it running on my Pentium that I could care less! : > I've just compiled kaleid.icn and now I can't get Fvwm nor the other : > X-Windows desktops to recognize it. I tried placing it in the : > apps-default directory but still no cigar. : > How do I run these cool new Icon things? of course, just typing in : > the name from a shell doesn't do it (although I did try that). : You should simply run it from a shell, I'm afraid. fvwm and other : managers have fancier ways of doing it, but essentially all they do is : execute the program. I get "bad mainwin" when run from a terminal shell inside of FVWM. Any ideas? : Do any of your other X programs work? If not, then perhaps you've got : DISPLAY set incorrectly, or something similarly silly. Otherwise it : looks as though there's something wrong with your icon installation. X-Windows is running great. I'm so glad to be back in a multi-tasking enviroment (as an Amiga owner). Just for the record, though, the Linux ICON requires that iconx be put in a directory called: /home/jeffery/bin/v9/ So, I just did what it demanded and placed iconx there until I soft-link it, or re-compile the sources myself. Other non-X-Windows Icon programs work fine; I've finally got the chance to use iconc. Any help or suggestions would be much appreciated. Could someone tell me the basic doc for V9.0's new features? The binary package came with docs about the widgets library and vib and that was it. Thanks to everybody! -- Jeff Harrington idealord@dorsai.dorsai.org -- (*) Most Beautiful Site on the Net: Net in Arcadia http://www.parnasse.com/(*) (*) Elsie Russell's Pics! Jeff Harrington's Music ->>>> Art + The Bizarre (*) (*) Jeff's Musical WWW Site->>>> http://www.parnasse.com/jeff.htm (*) (*) IdEAL ORDER Psychic TV - All Days But Thursdays(ABC) on CBS Since 1984 (*) From icon-group-sender Sat Jul 8 11:14:48 1995 Received: by cheltenham.cs.arizona.edu; Sat, 8 Jul 1995 18:04:30 MST Date: Sat, 8 Jul 1995 11:14:48 MST From: "Ralph Griswold" Message-Id: <199507081814.AA07120@cheltenham.cs.arizona.edu> To: icon-group Subject: The Icon Analyst Errors-To: icon-group-errors@cs.arizona.edu The Icon Analyst is a technically oriented newsletter dedicated to in-depth coverage of the Icon programming language. The Icon Analyst is published bi-monthly. Here's the contents of the first 30 issues. Issue 1, August 1990 Launching the Analyst ... 1 Version 8 Overview ... 1-3 Getting Started with Icon ... 3-6 Programming Tips ... 6 Memory Monitoring ... 7-10 Benchmarking Expressions ... 10-12 What's Coming Up ... 12 Issue 2, October 1990 Expression Evaluation ... 1-2 Syntactic Pitfalls ... 3-5 Memory Monitoring ... 5-9 Programming Tips ... 9 Benchmarking Expressions ... 10-11 From the Wizards ... 12 What's Coming Up ... 12 Issue 3, December 1990 Program Readability ... 1 Writing Portable Icon Programs ... 2-4 String Scanning ... 5-7 Generators ... 8-10 Programming Tips ... 11 From the Wizards ... 12 What's Coming Up ... 12 Issue 4, February 1991 Programs that Write Programs ... 1-2 Writing Scanning Expressions ... 2-5 Large Integers ... 5-6 Memory Utilization ... 7-10 From the Wizards ... 10-11 Programming Tips ... 11 Thanks and Credits ... 11-12 Feedback ... 12 What's Coming Up ... 12 Issue 5, April 1991 String Scanning Examples ... 1-6 Pattern Matching ... 6-10 Gedanken Debugging ... 10 Programming Tips ... 11-12 Subscription Renewal ... 12 What's Coming Up ... 12 Issue 6, June 1991 Modeling String Scanning ... 1-2 Pointer Semantics ... 2-8 Evaluation Sandwiches ... 8-10 Program Termination ... 10-11 Programming Tips ... 12 What's Coming Up ... 12 Issue 7, August 1991 String Synthesis ... 1 Variant Translators ... 2-5 Result Sequences ... 5-8 Procedure Libraries ... 8-11 Corrections ... 12 Programming Tips ... 12 What's Coming Up ... 12 Issue 8, October 1991 String Synthesis ... 1-2 An Imaginary Icon Computer ... 2-6 Augmented Assignment Operations ... 7-8 The Icon Compiler ... 8-11 Programming Tips ... 12 What's Coming Up ... 12 Issue 9, December 1991 Bogus Expressions ... 1-2 A String Evaluator ... 2-4 String Allocation ... 4-7 Type Inference in the Icon Compiler ... 7-11 Programming Tips ... 11-12 What's Coming Up ... 12 Issue 10, February 1992 Getting to the System ... 1-2 Procedural Encapsulation ... 3-4 The Anatomy of a Program ... 4-9 Writing Bullet-Proof Programs ... 9-11 Programming Tips ... 12 What's Coming Up ... 12 Issue 11, April 1992 Data Representation: A Case Study ... 1-5 Modeling Icon Functions ... 5-7 Command-Line Arguments ... 7-10 Programming Tips ... 11 From Our Readers ... 12 What's Coming Up ... 12 Issue 12, June 1992 Exercises ... 1 Anatomy of a Program ... 2-4 Inside the Icon Compiler ... 4-9 Programming Tips ... 9-11 Looking Ahead ... 11 Reader Feedback ... 12 Issue 13, August 1992 Face Lift for the Analyst ... 1 Solutions to Exercises ... 1-4 An Introduction to X-Icon ... 5-10 Programming Tips ... 10-12 What's Coming Up ... 12 Issue 14, October 1992 Reader Feedback ... 1 Arrays ... 2-4 Idiomatic Programming ... 4-8 Multi-Thread Icon ... 8-12 What's Coming Up ... 12 Issue 15, December 1992 Idiomatic Programming ... 1-5 Monitoring Icon Programs ... 6-10 Programming Tips ... 11-12 What's Coming Up ... 12 Issue 16, February 1993 Program Visualization ... 1-8 Sparse Arrays ... 9-12 What's Coming Up ... 12 Issue 17, April 1993 Lost Languages -- SL5 ... 1-7 Drawing in X-Icon ... 7-11 Subscription Renewal ... 12 What's Coming Up ... 12 Issue 18, June 1993 Lost Languages -- Rebus ... 1-4 Text in X-Icon ... 4-7 Anatomy of a Program ... 8-11 From the Wizards ... 12 Subscription Renewal ... 12 What's Coming Up ... 12 Issue 19, August 1993 Lost Languages -- Seque ... 1-4 Handling Events in X-Icon ... 4-5 Anatomy of a Program ... 6-10 Programming Tips ... 10-12 What's Coming Up ... 12 Issue 20, October 1993 Exercises ... 1 Icon Made Difficult ... 1-2 Dealing with Windows in X-Icon ... 3-5 Piped Scanning... 6-9 Solutions to Exercises ... 9-10 Programming Tips ... 11-12 What's Coming Up ... 12 Issue 21, December 1993 Returning Multiple Values ... 1-4 Graphic Contexts in X-Icon ... 5-7 Procedures with Memory ... 8-12 What's Coming Up ... 12 Issue 22, February 1994 Procedures with Memory ... 1-4 Color in X-Icon ... 5-7 Programmer-Defined Control Operations ... 8-12 What's Coming Up ... 12 Issue 23, April 1994 Programmer-Defined Control Operations ... 1-4 Color in X-Icon ... 5-7 Meta-Variant Translators ... 8-10 Programming Tips ... 11-12 What's Coming Up ... 12 Issue 24, June 1994 Handline Images in X-Icon ... 1-2 From the Library ... 2-6 Turtle Graphics ... 6-10 Programming Tips ... 10-11 A Word of Thanks ... 12 Reflections ... 12 What's Coming Up .. 12 Issue 25, August 1994 From the Library ... 1-5 Anatomy of a Program ... 5-9 From the Wizards ... 10 Programming Tips ... 10-12 What's Coming Up ... 12 Issue 26, October 1994 Random Numbers ... 1-3 Trivia Quiz ... 3-4 Lindenmayer Systems ... 4-9 Answers to the Trivia Quiz ... 9 Cheap Tricks ... 9-11 Programming Tips ... 11-12 What's Coming Up ... 12 Issue 27, December 1994 Lindenmayer Systems ... 1-5 Static Analysis of Icon Programs ... 5-11 Programming Tips ... 11-12 What's Coming Up ... 12 Issue 28, February 1995 String Invocation ... 1-4 Random Number Generators ... 4-6 Lindenmayer Systems ... 6-9 Dynamic Analysis of Icon Programs ... 9-12 What's Coming Up ... 12 Issue 29, April 1995 New Area Code ... 1 Procedure and Operator Values ... 1-3 Applications of String Invocation ... 3-6 Curiosity or Problem? ... 6 From the Library ... 7-9 Dynamic Analysis of Icon Programs ... 10-12 Subscription Renewal ... 12 What's Coming Up ... 12 Issue 30, June 1995 Substriction Renewal ... 1 The Versum Problem ... 1-4 From the Wizards ... 5-6 Bogus Expressions ... 6 Dynamic Analysis ... 6-11 Programming Tips ... 12 What's Coming Up ... 12 A one-year (six issue) subscription to the Icon Analyst is $25 in the United States, Canada, and Mexico. It is $35 to other countries. To get a free sample copy of the Analyst, to subscribe, or to purchase back issues contact the Icon Project: Icon Project Department of Computer Science Gould-Simpson Building The University of Arizona Tucson, Arizona 85721 USA Voice: (520) 621-6613 FAX: (520) 621-4246 Electronic mail: icon-order@cs.arizona.edu From icon-group-sender Sat Jul 8 22:25:33 1995 Received: by cheltenham.cs.arizona.edu; Sun, 9 Jul 1995 18:03:52 MST Date: Sat, 8 Jul 1995 22:25:33 -0500 From: jeffery@runner.jpl.utsa.edu (Clinton L. Jeffery) Message-Id: <9507090325.AA17824@runner.utsa.edu> To: idealord@dorsai.dorsai.org Cc: icon-group@cs.arizona.edu In-Reply-To: (idealord@dorsai.dorsai.org) Subject: Re: Icon V9.0 X Windows Question Content-Length: 1075 Errors-To: icon-group-errors@cs.arizona.edu > I get "bad mainwin" when run from a terminal shell inside of FVWM. Any > ideas? As others point out, the DISPLAY environment variable is your most likely problem here. The other less likely prospect is some sort of incompatibility of the binaries with your version of Linux; Linux kernels change often. Some Icon programs might ask for a color or font that could cause a window open to fail, but I doubt that's the case here. > Just for the record, though, the Linux ICON > requires that iconx be put in a directory called: > /home/jeffery/bin/v9/ Obviously this is my fault :-) but the program called patchstr should let you relocate the iconx binary to anywhere you want. You have to run the patchstr program on icont to tell icont where you're putting iconx. Another option is to set your ICONX environment variable. Either way, you should not need a "/home/jeffery" directory on your system... :-) Recompiling the sources for yourself is good for the soul, though. Clint Jeffery jeffery@ringer.cs.utsa.edu The University of Texas at San Antonio From icon-group-sender Sun Jul 9 10:26:11 1995 Received: by cheltenham.cs.arizona.edu; Sun, 9 Jul 1995 18:17:55 MST From: Nick Williams Message-Id: <199507091426.KAA23919@ios.com> Subject: Closures in Icon? Is it too late for a new feature to creep in? To: icon-group@cs.arizona.edu Date: Sun, 9 Jul 1995 10:26:11 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1835 Errors-To: icon-group-errors@cs.arizona.edu One of the various features of LISP that I absolutely love is closures, or, more accurately, the ability to produce new functions dynamically. I'd like to see something like that in Icon, except that I'm not about to propose anything like LISP's eval or even true LISP closures, but how about this: procedure TestClosure(var1, var2, ...) environment catch_this_var, and_this_one ... end procedure MakeTestClosure() local catch_thisvar, and_this_one ... return closure(TestClosure) end The 'closure' function would make a copy of the 'catch_this_var' and 'and_this_one' descriptors and store them in a new b_proc structure (procedure header). The variables declared in the 'environment' clause are equivalent to static, and are initialized to &null unless the function is closed over inside a function which has local variables of the same name, or unless there are globals of those names with values other than &null; additionally, the closure() function could perhaps take extra arguments to initialize any remaining, non-caught closure variables. By not storing references to the variables closed over we get semantics very different from LISP's: not real closures, but better than nothing, and it would be easy to implement (a few mods to h/rstructs.h, the GC, a few other places and the 'closure' function I bet). This scheme could probably be extended a bit so that multiple functions could share one 'environment' (by defining the 'environment' outside the procedure declaration and giving it a name, declaring the participation in that environment declaration in the procedure defs, and having closure() take multiple procedure arguments and so on). Wouldn't Icon be more interesting this way? :) Nick PS: forgive my terminology, I know it's loose, but I'm not at home, where I have all my comp. sci. books. y comp. sci. books. From icon-group-sender Mon Jul 10 16:11:53 1995 Received: by cheltenham.cs.arizona.edu; Mon, 10 Jul 1995 15:09:38 MST Date: Mon, 10 Jul 1995 16:11:53 -0500 (CDT) From: "Chris D. Tenaglia" To: icon-group@cs.arizona.edu Subject: DOS delay routine Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@cs.arizona.edu Running Icon V9 for MSDOS V6.2 on a 486/100 Compaq. I wrote a little routine to monitor things on a Novell LAN. I needed something to wait about 5 min. between checkups do I wrote a little delay route that waits in a little key sensing loop. Under unix there is a delay() builtin procedure. In this routine it seems to get stuck waiting for the key. Has the key handler technique changed in this latest version? I haven't been able to coax it to working. Are there plans to incorporate such a builtin in DOS/Windows Icon in the future? Any suggestions as to a better or correct way? There are WAIT.COM programs but there's not much memory left for system("wait 00:00:05") type calls. On my PC, delay(2) waits about 5 minutes (or it used to), but now it just hangs. When ESC is pressed it exits through the halt procedure. Thanx in advance, Chris. # # provide a time delay to limited amount of collected data # procedure delay(n) target := n * 250000 # approx 5 min intervals every i:= 1 to target do { if kbhit() then { kee := getch() if kee == "\e" then halt("ESCAPED!") } 22.0000/7.0000000 } end Chris Tenaglia (system manager) | cdt@post.its.mcw.edu Medical College of Wisconsin | 8701 W. Watertown Plank Rd. | Ce que vous voyez est Milwaukee, WI 53226 (414)456-8765 | ce que vous obtenez ! From icon-group-sender Mon Jul 10 16:49:00 1995 Received: by cheltenham.cs.arizona.edu; Mon, 10 Jul 1995 15:11:54 MST Message-Id: <9507101649.AA26606@ns1.computek.net> Mime-Version: 1.0 Content-Length: 10945 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 10 Jul 95 16:49 CDT From: gep2@computek.net Subject: Snobol & System programming To: karczma@calvin.info.unicaen.fr Cc: icon-group@cs.arizona.edu X-Mailer: SPRY Mail Version: 04.00.06.17 Errors-To: icon-group-errors@cs.arizona.edu >Alors, tu as passe 9 ans a Paris. Je crois maintenant que tu as eu quelques occasions to begin to hate cars. Muy bien. Heheheh... claro que si, c'est dificil garer a Paris... I've now lived in numerous places with quite different approaches to mass/public/personal transit and it's given me some hopefully-worthwhile observations on the subject. >Still, you are younger than I, although your computing career might be a bit longer. The point is that I have been for some time a theoretical physicist. Fun stuff... >I don't think there is a consensus on the merits/demerits of the explicit branching instruction as compared with while/select GodKnowsWhatElse. Do whatever you choose, but - please - there are two points which make it utterly impossible for me to adopt your attitude: Fair enough, as long as you don't expect me to adopt yours... >1. I teach programming languages, for many years already. Some structuring methods are simply impossible to avoid if you try to convey the coding strategies to the True Beginners. Rubbish. People taught programming languages for DECADES before the arrival of "structured programming concepts", and we did okay. > Perhaps for you a "break" is clumsier than :(DEHORS), It's not that it's necessarily clumsier, it's just a lot less obvious where "break" transfers control to. If you have a goto :(DEHORS) and a label DEHORS, then it's QUITE clear exactly where it's transferring to. There's not the slightest ambiguity, and you don't have to trust indenting, or count brackets or something to confirm things. > but I assure you that polluting the lexical space of the program with useless names is very harmful if you are a beginner. I claim that a 30-line text processing program in SNOBOL4 (and which maybe has a dozen labels in it) is FAR, FAR clearer than a 3500-line program in C (containing maybe a hundred function names) to do the same thing. You seem to think that labels are "pollution", I suggest that a lot of function names are every bit as bad (and just imagine how many labels OR function names you'd need in C to replicate the functionality of even a rather modest SNOBOL4 pattern match statement). > For the specialists, 'adultes et vaccines', comme les Francais used to say there is no problem, but if you teach, then you finally get stuck inside this particular philosophy which promotes modular programming. Snobol4 doesn't. (OK, OK, there are structuring preprocessors. But I don't like disguises). That's all ANY programming language/compiler is. C programs end up finally executing as GOTOs, just like SNOBOL4 or assembler or xBase or Pascal or Icon, it doesn't matter WHAT your source code says. >2. Have you ever tried to participate in a collective work, a program written by a dozen persons, 20 pages of code each? Physicists do it quite often. That's important when you write a 10,000 line program. But note that VERY few SNOBOL4 programs ever approach that length (the longest one I've written to date is probably around 2000 lines). It's not that they COULDN'T, of course... it's just that they VERY rarely NEED TO. > There is a (small) probability that you finally get mad at ANY control structures, not only at the jumps, but also at loops, computed gotos, selects, etcaetera. Then, you might think about hiding everything in Objects, or convert to a Functionalist/Logical Religion (independently of whether you are circumsized or not...). Frankly, I am quite pleased when I find that the language simply PROVIDES the features (and discipline) I need... intrinsically... that's the BEST way to 'hide everything' and make the programmer's job as easy as possible. > Icon might be used as a functional language, Perl also. There are some object-oriented structured at hand: Idol, or the whole OO-ref package of perl5. You can choose better your style. I'll be glad to ignore Perl, thankyouverymuch. >Style c'est l'homme, so I do not plan to get you into my sect, nor to teach you anything. Anyway your attitude towards teachers seems to be ambiguously negative, I'm not down on teachers 'per se', I've had some VERY fine ones (as well as a few REAL and TRUE dogs, I might add). I think it's unfortunate, however, that so many teachers will teach AWK and Perl and ignore things like SNOBOL4 (which I personally still consider a VERY attractive language) and Icon. >There are still some touchy points which you seem to disregard a bit. .... My problems are different, for example how to plug a program with textual output through a named pipe to Gnuplot or Matlab to produce the high quality graphic plots in a way transparent to the user. I can do it via Tcl or Perl. Where is the power of Snobol4 in this context? You can (at least -I- can) pipe input or output from SNOBOL4+ to other software programs, (to the extent that anyone can under MS-DOS in any case). One could even write a loadable module to do sprites and fast pixel graphics from SNOBOL4+ (although I've never felt the inclination/need to do so). Of course, the type of work YOU do and the type of work I do might be quite different, so YMMV. If you like Perl (and dislike SNOBOL4), then I can shake my head in wonderment, but ultimately can't control a matter that's clearly a question of your personal taste. >I have to administrate a primitive, but multi-user database accessible through WWW. this is an educative game where all users might try to update this database concurrently. I need lockf's or other blessed fcntl protection mechanisms; to make on the fly some symbolic links, to seek index files etc. I cannot simply spawn an external process which would do that, because I have to keep a permanent grip on the file handles. I really need a primitive tool library. "C" has it. Perl as well. Where is the Snobol4 power? If you can do it in C, there is NO reason you can't do it from SNOBOL4+ too. You can load a module under SNOBOL4+ written in assembler, that can do ANYTHING that any other assembler routine called from another language can do. >Can you give me an example of ONE CGI script written in Snobol4? I haven't looked, quite honestly. But I would assume that it's quite possible to do one. >B. Suppose you have a seminumerical problem to solve, a really nasty asymptotic expansion problem (for example in computational physics). The only *simple* way to program this is to use lazy semantics: streams or lazy lists. You have them for example in this "less powerful" Scheme. I didn't say that Scheme was "less powerful", I was talking about AWK and Perl. So please don't put words in my mouth. >You won't do them in Snobol4, and in Icon it is quite a task. Where is the power? And you'd write it in Perl, I expect. Right? If not, then what's your point? >What about first-order continuations which you might use to emulate threads, or apply in general to simulation programs? In Scheme you can do it. Again, I'm not talking about Scheme. I never mentioned the language, someone else did. Sure, you can point up specific programming tasks for which any given language is less than ideal. I never suggested that SNOBOL4 is perfect for everything. But neither is ANY OTHER single language, either. Heck, I can throw together a quick business database enter/update/inquire/report application in less than an hour or two in FoxPro that would take someone weeks to do in C, (OR Scheme OR whatever). Big deal. That doesn't mean that SNOBOL4 isn't ideal for a great many everyday programming tasks (and in fact, that's what I've found to be true). >I do not understand (please: although my English is very far from perfect, this is not the issue here) what do you mean by "people beating their noisy drum for a pitiful substitute...". I mean that there's a lot of people talking and making a big fuss about Perl and Awk, and when you get right down to it, neither one of them is nearly as interesting or useful (IMHO) as SNOBOL4 and Icon. >I don't think that Perl protagonists are more conspicuous, more agressive, less polite than many others. They are certainly more conspicuous and more aggressive than the Icon and SNOBOL4 fans are. And it's NOT because Awk and Perl are more interesting, useful, or powerful languages... it's clear that they are NOT. When I was back at Datapoint in R&D, I watched a friend and colleague... a REALLY NICE GUY... get verbally attacked and repeatedly badmouthed by another programmer there. The nice guy never rose up to defend himself (it wasn't his style) and eventually people started to believe the loudmouth asshole. So the nice guy finally got fired. Moral of the story? Don't let the loudmouths win by default, just because they make their presence felt more. Speak up for the little guys, the less-well-known, nicer alternatives. Don't allow yourself to get swept along in a tide, just because "everyone's doing it". >You see, I am from Poland. Welcome. I have many friends from (and still) there. >...one of the major points of my personal philosophy (you see, I have really had un coup d'oeil on your home-page) is the tolerance. I would never permit myself to accuse anybody of using a "pitiful substitute" of a programming language, because I would ask myself first: what do i want really? To offend him? To convince him? To prove that I am better than he? I primarily promote SNOBOL4 and Icon among my programming friends because I hope that they will find those languages useful and helpful, and because teaching a language to others (or interesting them in it) is a way to help keep a language alive. >Well, perhaps to make him think a bit. But is this a good way? In the case of SNOBOL4 and Icon, yes I think it is. I know that on FIDOnet and Intelec, a lot of people learned about SNOBOL4 and Icon because of me, that wouldn't have ever looked into them otherwise. And I know several friends there in Paris who nowadays use SNOBOL4 on at least an occasional basis that wouldn't have ever learned about the languages otherwise. One thing I have learned from the experience is that a lot of people cling DOGGEDLY to their old [t]rusty programming tools. You wouldn't believe how many loons claim they prefer PDS Basic to something like SNOBOL4 or Icon. And, I must confess, for some (even quite lucrative) programming projects, I'll use xBASE or even Databus as my preferred language... not because the language itself is particularly elegant, but because for certain types of jobs, it simply is the easiest, fastest, and most productive way to solve a problem and move forward. In any case, it's been interesting chatting with you about this stuff. I'm going ahead and copying the rest of the Icon group, in hopes that some of them will find it interesting too. Gordon Peterson http://www.computek.net/public/gep2/ From icon-group-sender Mon Jul 10 17:24:00 1995 Received: by cheltenham.cs.arizona.edu; Mon, 10 Jul 1995 16:07:36 MST Message-Id: <9507101724.AA28967@ns1.computek.net> Mime-Version: 1.0 Content-Length: 703 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 10 Jul 95 17:24 CDT From: gep2@computek.net Subject: DOS delay routine To: icon-group@cs.arizona.edu X-Mailer: SPRY Mail Version: 04.00.06.17 Errors-To: icon-group-errors@cs.arizona.edu >...I needed something to wait about 5 min. between checkups do I wrote a little delay route that waits in a little key sensing loop. # provide a time delay to limited amount of collected data # procedure delay(n) target := n * 250000 # approx 5 min intervals every i:= 1 to target do { if kbhit() then { kee := getch() if kee == "\e" then halt("ESCAPED!") } 22.0000/7.0000000 } end I'm curious why you didn't use &time or &clock to do this kind of thing, rather than just counting loop iterations or the like... if for no other reason than making your routine processor-speed-insensitive! Gordon Peterson http://www.computek.net/public/gep2/ From icon-group-sender Tue Jul 11 06:52:34 1995 Received: by cheltenham.cs.arizona.edu; Tue, 11 Jul 1995 08:48:33 MST Date: Tue, 11 Jul 1995 06:52:34 -0500 (CDT) From: "Chris D. Tenaglia" To: gep2@computek.net Cc: icon-group@cs.arizona.edu Subject: Re: DOS delay routine In-Reply-To: <9507101724.AA28967@ns1.computek.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@cs.arizona.edu That's a good suggestion. Thanks. I must have been thinking something along the line of benchmarks to keep it busy calculating, rather spinning on the clock. Actually I'd like it to "sleep" during the delay() rather than making the machine busy. Chris Tenaglia (system manager) | cdt@post.its.mcw.edu Medical College of Wisconsin | 8701 W. Watertown Plank Rd. | Ce que vous voyez est Milwaukee, WI 53226 (414)456-8765 | ce que vous obtenez ! On Mon, 10 Jul 1995 gep2@computek.net wrote: > Date: Mon, 10 Jul 95 17:24 CDT > From: gep2@computek.net > To: icon-group@cs.arizona.edu > Subject: DOS delay routine > > >...I needed something to wait about 5 min. between checkups do I wrote > a little delay route that waits in a little key sensing loop. > > # provide a time delay to limited amount of collected data > # > procedure delay(n) > target := n * 250000 # approx 5 min intervals > every i:= 1 to target do > { > if kbhit() then > { > kee := getch() > if kee == "\e" then halt("ESCAPED!") > } > 22.0000/7.0000000 > } > end > > I'm curious why you didn't use &time or &clock to do this kind of thing, rather > than just counting loop iterations or the like... if for no other reason than > making your routine processor-speed-insensitive! > > Gordon Peterson > http://www.computek.net/public/gep2/ > > > From icon-group-sender Tue Jul 11 11:07:00 1995 Received: by cheltenham.cs.arizona.edu; Tue, 11 Jul 1995 10:15:17 MST Message-Id: <9507111107.AA07634@ns1.computek.net> Mime-Version: 1.0 Content-Length: 439 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 11 Jul 95 11:07 CDT From: gep2@computek.net Subject: Re: DOS delay routine To: "Chris D. Tenaglia" Cc: icon-group@cs.arizona.edu X-Mailer: SPRY Mail Version: 04.00.06.17 Errors-To: icon-group-errors@cs.arizona.edu >That's a good suggestion. Thanks. You're welcome! >I must have been thinking something along the line of benchmarks to keep it busy calculating, That's okay, if the computer is running, it's busy calculating. :-) >rather spinning on the clock. Actually I'd like it to "sleep" during the delay() rather than making the machine busy. Digital machines don't wear out... :-) Gordon Peterson http://www.computek.net/public/gep2/ From icon-group-sender Tue Jul 18 02:56:33 1995 Received: by cheltenham.cs.arizona.edu; Tue, 18 Jul 1995 07:12:21 MST To: icon-group@cs.arizona.edu Date: Tue, 18 Jul 1995 02:56:33 GMT From: john@nmt.edu (John Shipman) Message-Id: <1995Jul18.025633.16512@nmt.edu> Organization: Zoological Data Processing Sender: icon-group-request@cs.arizona.edu Subject: A tutorial for the Icon programming language Errors-To: icon-group-errors@cs.arizona.edu As part of a Web-based help system for the New Mexico Tech Computer Center, I've written a modest tutorial for the Icon programming language. The URL is: http://www.nmt.edu/tcc/help/lang/icon/ -- John Shipman (js@cs.nmt.edu) ``Let's go outside and commiserate with nature.'' --Dave Farber From icon-group-sender Wed Jul 19 16:38:07 1995 Received: by cheltenham.cs.arizona.edu; Wed, 19 Jul 1995 13:05:35 MST To: icon-group@cs.arizona.edu Date: Wed, 19 Jul 1995 16:38:07 GMT From: cas@netcom.com (Charles A. Shartsis) Message-Id: Organization: NETCOM On-line Communication Services (408 261-4700 guest) Sender: icon-group-request@cs.arizona.edu Subject: Icon Vidgets Errors-To: icon-group-errors@cs.arizona.edu I just received the June issue of the Icon Newsletter and it contains screen shots of student projects from a graphics programming course in which Icon was used. Several of the screen shots show windows with 3D sculpted controls (buttons, scrollbars). How did they create these controls? The Vidgets provided in the current version of the Icon programming library don't seem to provide a 3D appearance. I doubt if these programs were created without access to some preexisting widget-like functionality. -- -- Charles A. Shartsis Logicon RDA From icon-group-sender Wed Jul 19 18:35:27 1995 Received: by cheltenham.cs.arizona.edu; Wed, 19 Jul 1995 16:20:40 MST To: icon-group@cs.arizona.edu Date: Wed, 19 Jul 1995 18:35:27 GMT From: idealord@dorsai.dorsai.org (Jeff Harrington) Message-Id: Organization: The Dorsai Embassy - New York Sender: icon-group-request@cs.arizona.edu References: Subject: Re: Icon for X-Windows Problems Errors-To: icon-group-errors@cs.arizona.edu I've re-compiled Icon V9.0 for Linux as Clint Jeffery suggested and it passes all of the tests - except for the test in the graphics directory. I know it found the X libraries as it compiles without errors and displays X-Windows Graphics as a feature. Now when I run a program it opens a window, lets you position it and then disappears. I've got the $DISPLAY variable set to "unix:0.0" as needed. Any clues as to what I'm doing wrong? 2Julia1.icn sits there for a while under fvwm and then disappears. At least the X-Windows programs are coming up, but now it's a little more frustrating, actually! I'm calling these from a Xterm window. Thanks... -- Jeff Harrington idealord@dorsai.dorsai.org -- (*) Most Beautiful Site on the Net: Net in Arcadia http://www.parnasse.com/(*) (*) Elsie Russell's Pics! Jeff Harrington's Music ->>>> Art + The Bizarre (*) (*) Jeff's Musical WWW Site->>>> http://www.parnasse.com/jeff.htm (*) (*) IdEAL ORDER Psychic TV - All Days But Thursdays(ABC) on CBS Since 1984 (*) From icon-group-sender Wed Jul 19 13:52:48 1995 Received: by cheltenham.cs.arizona.edu; Wed, 19 Jul 1995 16:20:52 MST To: icon-group@cs.arizona.edu Date: 19 Jul 1995 13:52:48 -0700 From: icon-project@cs.arizona.edu Message-Id: <3ujrb0$5b0@optima.cs.arizona.edu> Organization: University of Arizona CS Department, Tucson AZ Sender: icon-group-request@cs.arizona.edu Reply-To: icon-project@cs.arizona.edu Subject: Icon Programming Language FAQ Errors-To: icon-group-errors@cs.arizona.edu Archive-name: comp-lang-icon-faq Posting-Frequency: monthly Frequently Asked Questions About The Icon Programming Language last updated: 01/18/95 This FAQ answers various questions about the Icon programming language, ranging from what it is to how you can get it. This first version of the Icon FAQ is devoted to the issues that are likely to be of most interest to persons who don't know anything about Icon or who are relatively new to it. Future versions of this FAQ will answer questions from more experienced Icon programmers. This FAQ is written by Ralph Griswold with help from Cliff Hathaway, Clint Jeffery, and Gregg Townsend. Section I -- General Questions: I.1. What is Icon? I.2. What is Icon good for? I.3. Where did Icon come from? I.4. What does "Icon" stand for? I.5. On what computers does Icon run? I.6. Who did all these implementations? I.7. Are there other implementations in the works? I.8. Are there different versions of Icon? I.9. Which implementations of Icon have graphics/window capabilities? I.10. Where can I get Icon? I.11. Where can I get documentation about Icon? I.12. How do I get started with Icon? I.13. What is the Icon Project? I.14. Where can I find examples of Icon programs? I.15. What is Idol? I.16. How often is material in Icon's FTP area updated? I.17. How do I stay up to date with what's going on with Icon? I.18. Why isn't the Icon Newsletter available electronically? I.19. Is there a users' group for Icon? I.20. How do I get technical support? I.21. Is there an optimizing compiler for Icon? I.22. What do I need to run the interpreter? I.23. What do I need to run the compiler? I.24. Can I build my own implementation of Icon for a new platform? +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I.1. What is Icon? Icon is a very high level general-purpose programming language with extensive features for processing strings (text) and data structures. Icon is an imperative, procedural language with a syntax that is reminiscent of C and Pascal, but its semantics are at a much higher level than those languages. Icon has a novel expression-evaluation mechanism that integrates goal- directed evaluation and backtracking with conventional control structures. It has a string scanning facility for pattern matching that avoids the tedious details usually associated with analyzing strings. Icon's built-in data structures include sets and tables with associative lookup, lists that can be used as vectors or stacks and queues, and records. Icon is a strongly, though not statically, typed language. It provides transparent automatic type conversion. For example, if an integer is used in an operation that requires a string, the integer is automatically converted to a string. Several implementations of Icon have high-level graphics facilities with an easily programmed window interface. Icon manages storage automatically. Objects are created as needed during program execution and space is reclaimed by garbage collection as needed. The sizes of strings and data structures are limited only by the amount of available memory. I.2. What is Icon good for? As a general-purpose programming language with a large computational repertoire, Icon can be used for most programming tasks. It's at its best when used as a prototyping tool, for processing text, and when ease of programming is needed for experimental and research applications. Paradoxically, Icon is used most often for short, one-shot tasks and for very complex applications. Icon is designed to make programming easy; it emphasizes the value of programmer's time and the importance of getting programs to work quickly. This explains its usefulness for prototyping as well as the apparent paradox of applicability to simple and complex applications. I.3. Where did Icon come from? Icon is the latest in a series of high-level programming languages designed to facilitate programming tasks involving strings and structures. The original language, SNOBOL, was developed at Bell Telephone Laboratories in the early 60s. SNOBOL evolved into SNOBOL4, which is still in use. Subsequent languages were developed at The University of Arizona with support from the National Science Foundation. Incidentally, Icon bears little physical resemblance to SNOBOL4, although it has similar objectives and many similar capabilities. I.4. What does "Icon" stand for? The name Icon (which is not spelled ICON) is not an acronym nor does it stand for anything in particular, although the word iconoclastic was mentioned at the time the name was chosen. The name predates the now common use of "icon" to refer to small images used in graphical user interfaces. This latter usage sometimes causes persons to think mistakenly that Icon is designed to create or manipulate icons. There's not much that can be done about this. I.5. On what computers does Icon run? The implementation of Icon is highly portable. There are versions for the Acorn Archimedes, the Amiga, the Atari ST, IBM CMS and MVS, the Macintosh, MS-DOS, OS/2, UNIX, and VMS. Nearly 60 UNIX platforms are supported. Icon programs also are highly portable. Most Icon programs can run on any platform that supports Icon. I.6. Who did all these implementations? The original implementation of Icon for UNIX was done at The University of Arizona. Most of the other implementations originally were done by volunteers scattered around the world. It's worth noting that all implementations of Icon are based on the same source code, which is written in C. This contributes to the portability of Icon itself, as well as to the portability of programs written in Icon. I.7. Are there other implementations in the works? Yes, work is constantly underway on implementations of Icon for new platforms. Present projects include Windows NT, Win32, and a new Macintosh implementation. I.8. Are there different versions of Icon? Icon has evolved through a series of versions with improved and extended capabilities. The latest major version number is 9. This version includes recent changes and additions, notably in the graphics area. As of this writing, the MS-DOS, UNIX, and VMS implementations are are up to 9.0. Other implementations that presently are at Version 8.10 are being converted to 9.0. There are a few platforms still at 8.0. Almost all programs that run under 8.0 or 8.10 and that do not use graphics will run under 9.0. Programs that use graphics require conversion to 9.0. The 9.0 release provides conversion aids. I.9. Which implementations of Icon have graphics/window capabilities? Icon's graphics facilities presently are supported on the OS/2, UNIX, and VMS implementations. The UNIX and VMS implementations use X, while the OS/2 implementation uses Presentation Manager. The NT and Win32 implementations that are in progress will support Icon's graphics facilities. A Macintosh implementation to support graphics also is in the works. I.10. Where can I get Icon? Most implementations of Icon are available via anonymous FTP to ftp.cs.arizona.edu in /icon. The directory /icon/binaries contains executable versions of Icon for several systems, including several popular UNIX platforms. The directory /icon/packages contains source code, test programs, related material, and, most cases, executable binaries as well. All directories have READ.ME files with additional information. Icon also is available on a variety of physical media for prices ranging from $15 to $50. Contact: Icon Project Department of Computer Science The University of Arizona Tucson, AZ 85721 520-621-6613 (voice) 520-621-4246 (fax) icon-orders@cs.arizona.edu (e-mail) Request a copy of the Icon Newsletter for a listing of what's available and what the prices are. Purchases can be made by credit card (MasterCard, Visa, or Discover) or by check drawn on a bank with a branch in the United States and made payable to The University of Arizona. I.11. Where can I get documentation about Icon? The definitive work on Icon is the book The Icon Programming Language, Griswold and Griswold, Prentice-Hall, 1990, 368 pages, ISBN 0-13-447889-4. This book is a complete description and reference manual for Version 8 of Icon. There also is a book on the implementation of Icon: The Implementation of the Icon Programming Language, Griswold and Griswold, Princeton University Press, 1986, 336 pages, ISBN 0-691-08431-9. This book describes the implementation as of Version 6 of Icon. Although the implementation has changed somewhat since then, the basic structure is the same. Technical reports describing recent implementation changes are included with books purchased from the Icon Project. These books are available from the Icon Project or from any book store that handles special orders. Additional documentation is available via FTP in /icon/doc. Notable documents are: TR 90-6 an overview of Icon IPD255 graphics/window facilities IPD236 changes between Versions 8.0 and 9.0 There are manual pages for UNIX systems, but there is no complete on-line documentation. The Icon Newsletter, which includes topical material about Icon and a list of material available from the Icon Project, is published three times a year. Subscriptions are free; contact the Icon Project to get a copy of the latest Newsletter and to be put on the mailing list. The Icon Analyst, a technically oriented newsletter that features articles about programming, is published six times a year. There is a subscription fee for the Analyst. A sample copy is available on request. All back issues of both newsletters are available for purchase. I.12. How do I get started with Icon? If you're a newcomer to Icon, get the package for your platform (by FTP, cd /icon/packages and get READ.ME for more information). This will give you documentation concerning running Icon on your platform, test programs and other material. If the package you pick up does not contain executable files, see /icon/binaries. You also may want to get the overview of Icon: /icon/doc/tr90-6.doc or tr90-6.ps.Z. You'll find pointers to other documents of interest in the package you pick up. I.13. What is the Icon Project? The Icon Project is a name used by the group at The University of Arizona that develops, implements, distributes, and supports the Icon programming language. The Icon Project is not commercial organization. It derives support from The University of Arizona, grants, and (primarily) revenue from the sale of program material and documentation. I.14. Where can I find examples of Icon programs? There is a large program library for Icon. It is an excellent resource for both new and experienced programmers, containing numerous examples of how to do things with Icon. The library also provides many useful applications, as well as hundreds of procedures that supplement Icon's built-in repertoire. The library, like other Icon material, is available via FTP (cd /icon/library) and on physical media from the Icon Project. I.15. What is Idol? Idol is an object-oriented extension to Icon that provides concepts such as classes and multiple inheritance. Idol is written in Idol and is distributed as part of the Icon program library. Idol runs on almost all of the platforms that Icon runs on. Additional Idol information is available from Clint Jeffery, jeffery@ringer.cs.utsa.edu. I.16. How often is material in Icon's FTP area updated? New material is added when it's available. Established implementations usually are only updated when there's a major new release. This typically is every year or two. The Icon program library is updated on a similar schedule. I.17. How do I stay up to date with what's going on with Icon? The best way to find out about developments related to Icon is to subscribe to the Icon Newsletter. It's free, but it is distributed only by postal mail, so you must provide a mailing address. You can stay up to date on the source code, which is changed much more frequently than the version on FTP is updated, by subscribing to the source update service, which provides a new version about three times a year. There also is a subscription service for updates to the Icon program library, which provides new material three or four times a year. See the Icon Newsletter for information about subscribing to these services. I.18. Why isn't the Icon Newsletter available electronically? The Icon Newsletter contains diagrams, images, and other material that cannot be rendered in plain ASCII text. The Newsletter is prepared with a desktop publishing system that produces PostScript, but the files are enormous -- too large to include in the Icon FTP area. Selected articles from the Newsletter are available by FTP in /icon/doc/articles. I.19. Is there a users' group for Icon? There is no official Icon users' group. The Icon Project maintains an electronic mailing list, icon-group@cs.arizona.edu. Mail sent to this address is forwarded to subscribers. To subscribe (or unsubscribe), send a message to icon-group-request@cs.arizona.edu. There is a gateway between icon-group and comp.lang.icon, an unmoderated newsgroup for discussing issues related to Icon. The gateway, which exchanges messages between the two systems, is imperfect and not under the control of the Icon Project. The newsgroup generally provides faster response than the mailing list. The newsgroup is less intrusive, but it sometimes suffers from inappropriate postings. The Icon Project usually sends messages of interest to the Icon community to icon-group. I.20. How do I get technical support? Free technical support is available from the Icon Project via electronic mail to icon-project@cs.arizona.edu or by fax, telephone, and postal mail to the Icon Project as listed above. Since the Icon Project is not a commercial organization, support is limited to what it can provide with its available resources. If the Icon Project cannot help with a problem (such as for a platform it doesn't have), it will attempt to provide a contact with someone who can help. I.21. Is there an optimizing compiler for Icon? Yes. The original implementation was an interpreter. An optimizing compiler was added a few years ago. The interpreter and compiler are largely source-language compatible. The interpreter is used by most Icon programmers because it gets into execution quickly and runs fast enough for most applications. The compiler is best suited for applications that require the fastest possible execution time. In this case, it's generally best to develop the program using the interpreter and then compile the final result for production use. I.22. What do I need to run the interpreter? The Icon interpreter will run on most computers. It requires a reasonable amount of memory, however. Under MS-DOS, the Icon interpreter needs 500KB of application RAM to work well. I.23. What do I need to run the compiler? The Icon compiler is another matter. It requires a C compiler, a fast CPU for tolerable compilation times, a considerable amount of disk space, and a lot of memory -- at least several megabytes. The Icon compiler generates C code, which must then be compiled to produce an executable program. The flexibility that Icon provides to programmers makes compilation technically difficult and the process requires a large amount of memory. The C code it produces is voluminous and stresses the most robust C compilers. Generally speaking, the Icon compiler is practical for platforms in the workstation class but not for most personal computers. Although the compiler can be built and made to run on 286 platforms running standard MS-DOS, only trivially small programs can be compiled. In principle, the Icon compiler is practical on MS-DOS 386/486 platforms with extended memory, but the limited availability of suitable 32-bit C compilers for this environment has discouraged the use of the Icon compiler on such platforms. I.24. Can I build my own implementation of Icon for a new platform? As mentioned above, Icon is written in C and the source code is available via FTP and the Icon Project. The existing implementations are testament to its portability. (a small amount of assembly-language code is required for a context switch, but this is only needed for an optional feature -- co-expressions -- that can be disabled without affecting most of Icon.) New ports involve platform-specific configuration parameters and, in some cases, platform-specific code. The feasibility of a new port and the amount of work it may take depends on the platform -- its architecture, its C compiler, and its environment. Ports to new UNIX platforms generally are easy, although novel architecture may present problems. Ports to new operating systems generally are more difficult, especially if Icon's graphics facilities are implemented. The Icon Project provides what help it can with new ports. In return, it asks that code related to the port to be returned to the Icon Project for inclusion in future versions of the source code for Icon. This makes the new port available to others as well as to the porter when Icon is updated. From icon-group-sender Wed Jul 19 21:01:00 1995 Received: by cheltenham.cs.arizona.edu; Thu, 20 Jul 1995 06:58:51 MST Message-Id: Date: Wed, 19 Jul 95 21:01 CDT From: escargo@mirage.skypoint.com To: idealord@dorsai.dorsai.org (Jeff Harrington), icon-group@cs.arizona.edu Subject: Re: Icon for X-Windows Problems Content-Length: 71 Errors-To: icon-group-errors@cs.arizona.edu You might try compiling with tracing turned on, and see where it dies. From icon-group-sender Thu Jul 20 20:51:24 1995 Received: by cheltenham.cs.arizona.edu; Fri, 21 Jul 1995 09:09:59 MST To: icon-group@cs.arizona.edu Date: Thu, 20 Jul 1995 20:51:24 GMT From: idealord@dorsai.dorsai.org (Jeff Harrington) Message-Id: Organization: The Dorsai Embassy - New York Sender: icon-group-request@cs.arizona.edu References: , Subject: Re: Icon for X-Windows Problems Errors-To: icon-group-errors@cs.arizona.edu Sorry to follow-up to my own posting, but I forgot to include some information. In every case of failure, the program is not finding an important argument. It's always a null while expecting an integer or procedure. It's a Main failure (I'm typing this from work). Seems like some kind of communication problem between the X-Windows server and iconx? These programs fail the same way regardles of supplied arguments. julia1 fails after sitting there for a while regardless of if I give it a 1.0 0.0 argument list or not. Any ideas from the X-Windows gurus? I'm a total newbie... just happy to have it running and interested in seeing what Icon can do within its confines.... Thanks! Jeff Harrington idealord@dorsai.dorsai.org -- (*) Most Beautiful Site on the Net: Net in Arcadia http://www.parnasse.com/(*) (*) Elsie Russell's Pics! Jeff Harrington's Music ->>>> Art + The Bizarre (*) (*) Jeff's Musical WWW Site->>>> http://www.parnasse.com/jeff.htm (*) (*) IdEAL ORDER Psychic TV - All Days But Thursdays(ABC) on CBS Since 1984 (*) -- Jeff Harrington idealord@dorsai.dorsai.org -- (*) Most Beautiful Site on the Net: Net in Arcadia http://www.parnasse.com/(*) (*) Elsie Russell's Pics! Jeff Harrington's Music ->>>> Art + The Bizarre (*) (*) Jeff's Musical WWW Site->>>> http://www.parnasse.com/jeff.htm (*) (*) IdEAL ORDER Psychic TV - All Days But Thursdays(ABC) on CBS Since 1984 (*) From icon-group-sender Fri Jul 21 13:06:17 1995 Received: by cheltenham.cs.arizona.edu; Fri, 21 Jul 1995 16:20:38 MST Date: Fri, 21 Jul 1995 13:06:17 -0700 From: Gregg Townsend Message-Id: <9507212006.AA17984@hawk.CS.Arizona.EDU> To: cas@netcom.com, icon-group Subject: Re: Icon Vidgets Errors-To: icon-group-errors@cs.arizona.edu Date: Wed, 19 Jul 1995 16:38:07 GMT From: cas@netcom.com (Charles A. Shartsis) I just received the June issue of the Icon Newsletter and it contains screen shots of student projects from a graphics programming course in which Icon was used. Several of the screen shots show windows with 3D sculpted controls (buttons, scrollbars). How did they create these controls? The Vidgets provided in the current version of the Icon programming library don't seem to provide a 3D appearance.... The next release of the Icon Program Library, planned for this fall, will include the 3-D vidgets and a 3-D version of VIB. The students used an early version of this library to create their projects. We also expect to package up a minor update of Icon itself that will correct a few bugs and misfeatures we discovered over the past year. That will also be ready sometime this autumn. Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 520 621 4325 gmt@CS.Arizona.EDU 110 57 16 W / 32 13 45 N / +758m From icon-group-sender Sat Jul 22 12:16:07 1995 Received: by cheltenham.cs.arizona.edu; Mon, 24 Jul 1995 09:54:44 MST To: icon-group@cs.arizona.edu Date: 22 Jul 1995 12:16:07 GMT From: yschung2@se.cuhk.hk (JASON ~{UES}3I~}) Message-Id: <3uqq67$pdc@eng_ser1.erg.cuhk.hk> Organization: Engineering Faculty CUHK Sender: icon-group-request@cs.arizona.edu References: <1995Jul18.025633.16512@nmt.edu> Subject: Re: A tutorial for the Icon programming language Errors-To: icon-group-errors@cs.arizona.edu john@nmt.edu (John Shipman) writes: >As part of a Web-based help system for the New Mexico Tech >Computer Center, I've written a modest tutorial for the Icon >programming language. The URL is: > http://www.nmt.edu/tcc/help/lang/icon/ There is a mirror URL at: http://www.se.cuhk.hk/~snowball/using_icon (If there is any violation of copyright, please let me know. Thanks for your attention.) Regards, -- _/_/_/_/_/ _/_/_/_/ _/_/_/_/ _/ // Cheung Y. S. Jason _/ _/ _/_/ _/ _/_/ _/ // ~{UES}3I~} 1i(|&( _/_/_/_/ _/_/ _/ _/ _/_/ // yschung2@se.cuhk.hk _/_/ _/_/_/_/_/_/_/_/_/ _/ // http://www.se.cuhk.hk/~yschung2 From icon-group-sender Sun Jul 23 00:38:37 1995 Received: by cheltenham.cs.arizona.edu; Mon, 24 Jul 1995 09:55:12 MST To: icon-group@cs.arizona.edu Date: Sun, 23 Jul 1995 00:38:37 GMT From: dkuhlman@netcom.com (G. David Kuhlman) Message-Id: Organization: NETCOM On-line Communication Services (408 261-4700 guest) Sender: icon-group-request@cs.arizona.edu Subject: Compile Icon to Java VM? Errors-To: icon-group-errors@cs.arizona.edu Has anyone at the Icon Project thought about compiling Icon to the byte-code for the Java virtual/abstract machine? Has anything been written up about it? I'd like to know about whether it is feasible, advantages and disadvantages, etc. One advantage -- A compiled Icon application would run on Actually, I don't have one yet (for my 486 PC running Linux), but I'm betting that I will soon. Java people claim that Java programs compiled to byte-code can be translated to machine code for the processor on which they are being executed. This sounds very exciting. I thought, Wow! It would be neat if my Icon programs could do that. Doesn't this sound like a good idea for some U of A grad student in Computer Science who is looking for a project? I thought so. -- ---------------------- Dave Kuhlman Reify, Redwood City, CA Internet: dkuhlman@netcom.com ---------------------- From icon-group-sender Sun Jul 23 02:53:43 1995 Received: by cheltenham.cs.arizona.edu; Mon, 24 Jul 1995 09:55:26 MST Date: Sun, 23 Jul 1995 02:53:43 -0500 From: jeffery@runner.jpl.utsa.edu (Clinton L. Jeffery) Message-Id: <9507230753.AA06175@runner.utsa.edu> To: idealord@dorsai.dorsai.org Cc: icon-group@cs.arizona.edu In-Reply-To: (idealord@dorsai.dorsai.org) Subject: Re: Icon for X-Windows Problems Content-Length: 1146 Errors-To: icon-group-errors@cs.arizona.edu [Jeff Harrington has been sharing a difficulty in running version 9 graphics programs on his Linux platform.] In every case of failure, the program is not finding an important argument. It's always a null while expecting an integer or procedure. Seems like some kind of communication problem between the X-Windows server and iconx? No, you get this Icon error message when you are calling a procedure that doesn't exist or wasn't linked in. From the line # and description in the error message you should be able to tell us exactly what procedure was being called. From icon-group-sender Sun Jul 23 14:02:52 1995 Received: by cheltenham.cs.arizona.edu; Mon, 24 Jul 1995 09:56:36 MST To: icon-group@cs.arizona.edu Date: Sun, 23 Jul 1995 14:02:52 GMT From: idealord@dorsai.dorsai.org (Jeff Harrington) Message-Id: Organization: The Dorsai Embassy - New York Sender: icon-group-request@cs.arizona.edu Subject: Got Icon X-Windows Running Errors-To: icon-group-errors@cs.arizona.edu Thanks to Clint Jeffery for the great help in getting my Linux X-Windows capable Icon running. You guys did a fantastic job! With the iconc compiler, now I can create stand-alone X-Windows apps with a minimum of coding. It's an amazing system. Wonder what we could do to publicize its capabilities? Thanks to all and especially to Clint Jeffery for the help! -- Jeff Harrington idealord@dorsai.dorsai.org -- (*) Most Beautiful Site on the Net: Net in Arcadia http://www.parnasse.com/(*) (*) Elsie Russell's Pics! Jeff Harrington's Music ->>>> Art + The Bizarre (*) (*) Jeff's Musical WWW Site->>>> http://www.parnasse.com/jeff.htm (*) (*) IdEAL ORDER Psychic TV - All Days But Thursdays(ABC) on CBS Since 1984 (*) From icon-group-sender Sun Jul 23 19:42:50 1995 Received: by cheltenham.cs.arizona.edu; Mon, 24 Jul 1995 09:56:57 MST To: icon-group@cs.arizona.edu Date: 23 Jul 1995 19:42:50 GMT From: sp106@york.ac.uk ("stephen") Message-Id: <3uu8nq$2ui@mailer.york.ac.uk> Organization: a loss for words Sender: icon-group-request@cs.arizona.edu Subject: Finding Icon. Errors-To: icon-group-errors@cs.arizona.edu I know that ftp.cs.arizona.edu is the official site for Icon. But is there somewhere on the uk side of the transatlantic link that mirrors this? I find it impossible to get through to arizona most of the time. stephen -- ################################################### # sp106@york.ac.uk # http://www.york.ac.uk/~sp106 # # Shapes in the drink like Christ # # Cracks in the pale blue wall # ################################################### From icon-group-sender Sun Jul 23 02:53:43 1995 Received: by cheltenham.cs.arizona.edu; Mon, 24 Jul 1995 09:59:23 MST Date: Sun, 23 Jul 1995 02:53:43 -0500 From: jeffery@runner.jpl.utsa.edu (Clinton L. Jeffery) Message-Id: <9507230753.AA06175@runner.utsa.edu> To: idealord@dorsai.dorsai.org Cc: icon-group@cs.arizona.edu In-Reply-To: (idealord@dorsai.dorsai.org) Subject: Re: Icon for X-Windows Problems Content-Length: 1146 Errors-To: icon-group-errors@cs.arizona.edu [Jeff Harrington has been sharing a difficulty in running version 9 graphics programs on his Linux platform.] In every case of failure, the program is not finding an important argument. It's always a null while expecting an integer or procedure. Seems like some kind of communication problem between the X-Windows server and iconx? No, you get this Icon error message when you are calling a procedure that doesn't exist or wasn't linked in. From the line # and description in the error message you should be able to tell us exactly what procedure was being called. >From your earlier messages we know you've built binaries with graphics enabled, so my guess is you've got some funky problem with your Icon procedure library. Try the program procedure main() w := open("hello", "g") | stop("can't open window") write(w, "hello, world") Event(w) end to see if you have a working iconx and a valid DISPLAY environment variable. There is tracing you can turn on, and other ways to find out more about what is going on, if you need it. Clint Jeffery jeffery@ringer.cs.utsa.edu The University of Texas at San Antonio From icon-group-sender Mon Jul 24 12:56:27 1995 Received: by cheltenham.cs.arizona.edu; Mon, 24 Jul 1995 12:37:59 MST Date: Mon, 24 Jul 1995 12:56:27 -0500 From: jeffery@runner.jpl.utsa.edu (Clinton L. Jeffery) Message-Id: <9507241756.AA00761@runner.utsa.edu> To: dkuhlman@netcom.com Cc: icon-group@cs.arizona.edu In-Reply-To: Subject: Re: Compile Icon to Java VM? Content-Length: 944 Errors-To: icon-group-errors@cs.arizona.edu Has anyone at the Icon Project thought about compiling Icon to the byte-code for the Java virtual/abstract machine? I've looked at Java with some interest. What you suggest would be quite difficult though; compiling to a virtual machine that doesn't support goal-directed evaluation would be about as hard as compiling Icon to C, and we all know how hard that's proven to be. If the Java community (or one of the other very high level languages) decided that generators and goal-directed evaluation were worth implementing, it would make it much easier to do Icon-related hybrid work of this sort. My own personal interest in Java will depend on whether it is truly public domain with source available, or whether it is going to turn into a proprietary product at some point. Oh yes, and the fact that it is a C++ dialect makes me want to choke. :-) Clint Jeffery jeffery@ringer.cs.utsa.edu The University of Texas at San Antonio From icon-group-sender Mon Jul 24 13:32:49 1995 Received: by cheltenham.cs.arizona.edu; Mon, 24 Jul 1995 12:38:56 MST Message-Id: <9507241732.AA24223@cs> To: icon-group@cs.arizona.edu Cc: yschung2@se.cuhk.hk, john@nmt.edu Subject: Re: A tutorial for the Icon programming language In-Reply-To: Your message of "22 Jul 1995 12:16:07 GMT." <3uqq67$pdc@eng_ser1.erg.cuhk.hk> Date: Mon, 24 Jul 1995 13:32:49 -0400 From: Dave Hanson Errors-To: icon-group-errors@cs.arizona.edu From: yschung2@se.cuhk.hk (JASON ~{UES}3I~}) References: <1995Jul18.025633.16512@nmt.edu> Subject: Re: A tutorial for the Icon programming language john@nmt.edu (John Shipman) writes: >As part of a Web-based help system for the New Mexico Tech >Computer Center, I've written a modest tutorial for the Icon >programming language. The URL is: > http://www.nmt.edu/tcc/help/lang/icon/ There is a mirror URL at: http://www.se.cuhk.hk/~snowball/using_icon My 2.5 page "A Brief Introduction to Icon", which was published with Ralph's HOPL-II paper is available in http://www.cs.princeton.edu/~drh/icon.html. Feel free to copy it, if you'd like to add it to you Icon tutorial. (This introduction will also appear in the forthcoming HOPL-II book.) dave hanson From icon-group-sender Tue Jul 25 06:54:27 1995 Received: by cheltenham.cs.arizona.edu; Tue, 25 Jul 1995 08:35:27 MST To: icon-group@cs.arizona.edu Date: 25 Jul 1995 06:54:27 GMT From: "Le Baron O. Ferguson" Message-Id: <3v24f3$asa@galaxy.ucr.edu> Organization: University of California, Riverside Sender: icon-group-request@cs.arizona.edu Subject: snobol Errors-To: icon-group-errors@cs.arizona.edu Is snobol dead? Is there a newsgroup where I can post a question about snobol4? -- ============================================================================ Professor Le Baron O. Ferguson Office: Sproul 2219 Department of Mathematics (909) 787-5003 University of California ferguson@math.ucr.edu Riverside CA 92521 FAX : (909) 787-7314 The greatest failing of the human race is its inability to understand the exponential function. Anonymous. ============================================================================ From icon-group-sender Tue Jul 25 11:05:26 1995 Received: by cheltenham.cs.arizona.edu; Tue, 25 Jul 1995 12:27:01 MST Date: Tue, 25 Jul 1995 11:05:26 -0700 From: Gregg Townsend Message-Id: <9507251805.AA28259@hawk.CS.Arizona.EDU> To: icon-group@cs.arizona.edu, sp106@york.ac.uk Subject: Re: Finding Icon. Errors-To: icon-group-errors@cs.arizona.edu Date: 23 Jul 1995 19:42:50 GMT From: sp106@york.ac.uk ("stephen") I know that ftp.cs.arizona.edu is the official site for Icon. But is there somewhere on the uk side of the transatlantic link that mirrors this? I find it impossible to get through to arizona most of the time. It appears that ftp.gre.ac.uk is running an unofficial mirror in the directory /pub/languages/icon. Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 520 621 4325 gmt@CS.Arizona.EDU 110 57 16 W / 32 13 45 N / +758m From icon-group-sender Tue Jul 25 14:19:26 1995 Received: by cheltenham.cs.arizona.edu; Tue, 25 Jul 1995 12:27:12 MST To: icon-group@cs.arizona.edu Date: Tue, 25 Jul 1995 14:19:26 +0200 From: "Maarten v. Casteren" Message-Id: Organization: University of Nijmegen, The Netherlands Sender: icon-group-request@cs.arizona.edu Subject: ICON debugger? Errors-To: icon-group-errors@cs.arizona.edu I was wondering if there is a debugger available for the ICON programming language. I use the trace-mode sometimes, but find it more easy to print the value of a variable most of the times. A debugger would solve a lot of problems and save a lot of time for me. Maarten van Casteren, casteren@mpi.nl From icon-group-sender Wed Jul 26 09:45:30 1995 Received: by cheltenham.cs.arizona.edu; Wed, 26 Jul 1995 07:16:22 MST Comments: Authenticated sender is From: Jonathan Kaye Organization: S.O.A.S. To: icon-group@cs.arizona.edu Date: Wed, 26 Jul 1995 09:45:30 GMT Subject: wanted: vidget guru Reply-To: jk@soas.ac.uk X-Confirm-Reading-To: jk@soas.ac.uk X-Pmrqc: 1 Priority: normal X-Mailer: Pegasus Mail for Windows (v2.01) Message-Id: <792F085731@soas.ac.uk> Errors-To: icon-group-errors@cs.arizona.edu Is there a vidget guru out there with about 10 minutes to spare me. I'm trying to create a simple graphical interface for an Icon program and reading and rereading the docs is not getting me where I want to be. I have a feeling I need to understand couplers better. Here's what I want to do: imagine a frame with three vidgets: two buttons (call them "A" and "B" and one text box. What I want to do is click on a button and have the appropriate text (say, "A" or "B") appear in the text box. I'd like this to be cumulative so that later click are concatenated with whatever was in the text box previously. I'm sure this is ridiculously simple and I'm sorry about being thick. While I'm at it, what about setting toggle vidgets based on the contents of a file: suppose I have 3 toggles (1, 2 and 3) and some file with a single line that has 3 integers (boolean, 0 or 1). So I open the file and its one line reads: 010 I'd like to have toggle 2 set to on and 1 and 3 set to off. (I know ICON's values are 1 and &null in these cases). Can this be done. Thanks in advance for any and all help. Jonathan Kaye Department of Linguistics SOAS Tel. +44-171-323-6362 Fax. +44-171-323-6362 WWW. http://jk.soas.ac.uk :-) Not a spokesperson for SOAS (or vice versa) From icon-group-sender Thu Jul 27 11:22:00 1995 Received: by cheltenham.cs.arizona.edu; Thu, 27 Jul 1995 12:35:42 MST Message-Id: <9507271122.AA00292@ns1.computek.net> Mime-Version: 1.0 Content-Length: 433 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 27 Jul 95 11:22 CDT From: gep2@computek.net Subject: snobol To: icon-group@cs.arizona.edu X-Mailer: SPRY Mail Version: 04.00.06.17 Errors-To: icon-group-errors@cs.arizona.edu >Is snobol dead? Most certainly not!!!! It's just "mature". >Is there a newsgroup where I can post a question about snobol4? This one is good... I actually less than a week or two ago tried to create newsgroup alt.lang.snobol4 but wasn't successful, since not enough expressed interest apparently. But I'd be glad to try to answer any questions you might have on it. Gordon Peterson http://www.computek.net/public/gep2/ From icon-group-sender Thu Jul 27 12:18:50 1995 Received: by cheltenham.cs.arizona.edu; Thu, 27 Jul 1995 12:35:31 MST Date: Thu, 27 Jul 1995 12:18:50 -0700 From: Ralph Griswold Message-Id: <9507271918.AA01689@ursus.cs.arizona.edu> To: icon-group Subject: Icon Newsletter on the Web Errors-To: icon-group-errors@cs.arizona.edu The Icon Newsletter is now on the Web. To view it, go to Icon's home page http://www.cs.arizona.edu/icon/www/ and select The Icon Newsletter. There's also a link to The Icon Analyst and from it to a sample copy of the Analyst. Address any comments to ralph@cs.arizona.edu From icon-group-sender Thu Jul 27 07:29:09 1995 Received: by cheltenham.cs.arizona.edu; Thu, 27 Jul 1995 12:35:53 MST To: icon-group@cs.arizona.edu Date: 27 Jul 1995 07:29:09 GMT From: "Le Baron O. Ferguson" Message-Id: <3v7f85$l1a@galaxy.ucr.edu> Organization: University of California, Riverside Sender: icon-group-request@cs.arizona.edu Subject: snobol4 question Errors-To: icon-group-errors@cs.arizona.edu First I thank all the nice people who responded to my query about the demise of snobol and offered to answer my question. I am glad it is not dead and this is the proper forum for it. My problem is that I am using snobol4 to send control codes (among other things) to a printer. I assign to the variable OUTPUT. The output of the program is directed to the printer by /o=lpt2: on the command line. The problem is that the assignment to OUTPUT causes a newline to also be sent. I can program around this but it is aukward. In PASCAL we have WRITELN and WRITE, and the latter does not append a newline automatically. In C, printf simply does not send a newline unless you tell it to do so. Is there a corresponding mechanism in snobol4? I hope I am not wasting anyone's time. I looked for this in the "green" book and also the extensive documentation with snobol4. If there is a FAC I should read please just point me in its direction. Tnanks in advance. -- ============================================================================ Professor Le Baron O. Ferguson Office: Sproul 2219 Department of Mathematics (909) 787-5003 University of California ferguson@math.ucr.edu Riverside CA 92521 FAX : (909) 787-7314 The greatest failing of the human race is its inability to understand the exponential function. Anonymous. ============================================================================ From icon-group-sender Thu Jul 27 16:00:49 1995 Received: by cheltenham.cs.arizona.edu; Thu, 27 Jul 1995 16:37:17 MST Date: Thu, 27 Jul 1995 16:00:49 -0500 From: "Mark B. Emmer" Subject: Re: snobol4 question To: "Le Baron O. Ferguson" , "icon-group@cs.arizona.edu" Message-Id: <01HTDH9ZY0368WWAKM@MAILSRV1.PCY.MCI.NET> X-Mailer: e-mailMCI v2.3 Content-Transfer-Encoding: 7BIT Errors-To: icon-group-errors@cs.arizona.edu -- [ From: Mark B. Emmer * EMC.Ver #2.3 ] -- > From: Le Baron O. Ferguson \ Internet: (ferguson@math.ucr.edu) > To: icon-group@cs.arizona.edu \ Internet: (icon-group@cs.arizona.edu) ) > > Subject: snobol4 question > > My problem is that I am using snobol4 to send control codes (among other > things) to a printer. I assign to the variable OUTPUT. The output of the > program is directed to the printer by /o=lpt2: on the command line. The > problem is that the assignment to OUTPUT causes a newline to also be sent. I > can program around this but it is aukward. In PASCAL we have WRITELN and > WRITE, and the latter does not append a newline automatically. In C, printf > simply does not send a newline unless you tell it to do so. Is there a > corresponding mechanism in snobol4? If you're using SNOBOL4+, use a channel number on the command line, and the 'b' (binary) option in an explicit output statement: Command line: snobol4 progname /3=lpt2: Program statement: output('out',3,'b') That suppresses the automatic CR/LF. This won't work if you're using Vanilla SNOBOL4. The 'b' option was omitted. However, here's a cheat that will work with either system as long as you are writing to a character device, like lpt2: The old DOS end-of-file character control-Z will cause DOS to stop sending any data that follows in the same write operation. CHAR(26) is control-Z. So OUTPUT = 'abc' CHAR(26) writes the three characters 'abc' to the device, and does not output either the control-Z or the carriage-return/line-feed that follow. ---------------------------------------------------------------- Mark Emmer Catspaw, Inc. Voice: 719-539-3884 P.O. Box 1123 FAX: 719-539-4830 Salida, CO 81201 USA e-mail: Mark.Emmer@internetMCI.com ******************* NOTE NEW E-MAIL ADDRESS ************************ From icon-group-sender Fri Jul 28 20:01:00 1995 Received: by cheltenham.cs.arizona.edu; Sat, 29 Jul 1995 07:56:54 MST Message-Id: <9507282001.AA01864@ns1.computek.net> Mime-Version: 1.0 Content-Length: 418 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 28 Jul 95 20:01 CDT From: gep2@computek.net Subject: Re: snobol group To: ptho@loc.gov, icon-group@cs.arizona.edu X-Mailer: SPRY Mail Version: 04.00.06.17 Errors-To: icon-group-errors@cs.arizona.edu >How did you decide there wasn't enough interest? I don't recall any notices making it out. I posted several messages regarding creating the group in alt.config. We can certainly try again, if we can get some people (probably from this group) who will help lend some support to the group this time! I'd like to add a Databus language group at the same time. Gordon Peterson http://www.computek.net/public/gep2/ From icon-group-sender Tue Aug 1 08:41:09 1995 Received: by cheltenham.cs.arizona.edu; Tue, 1 Aug 1995 12:21:05 MST To: icon-group@cs.arizona.edu Date: 1 Aug 1995 08:41:09 -0700 From: dave@cs.arizona.edu (Dave Schaumann) Message-Id: <3vlhul$bfa@lectura.CS.Arizona.EDU> Organization: University of Arizona CS Department, Tucson AZ Sender: icon-group-request@cs.arizona.edu References: Subject: Re: ICON debugger? Errors-To: icon-group-errors@cs.arizona.edu In article , Maarten v. Casteren wrote: > >I was wondering if there is a debugger available for the ICON programming >language. I use the trace-mode sometimes, but find it more easy to print >the value of a variable most of the times. A debugger would solve a lot >of problems and save a lot of time for me. There's a couple of packages under ftp://cs.arizona.edu/icon/contrib: debug_tar.Z (also debug.zip) and itweak-2.2.tar.Z (also itweak.lzh). I would assume that "debug" is some kind of debugging package, and I know that "itweak" definitely is. However, I have never used either one, so I can't say how useful they are. I wrote a gdb-like debugger for Icon using MT Icon that's (IIRC) reasonably complete. If there's interest, I could make it available. -Dave From icon-group-sender Tue Aug 1 14:20:15 1995 Received: by cheltenham.cs.arizona.edu; Tue, 1 Aug 1995 12:20:55 MST To: icon-group@cs.arizona.edu Date: Tue, 1 Aug 1995 14:20:15 GMT From: dkuhlman@netcom.com (G. David Kuhlman) Message-Id: Organization: NETCOM On-line Communication Services (408 261-4700 guest) Sender: icon-group-request@cs.arizona.edu References: Subject: Re: ICON debugger? Errors-To: icon-group-errors@cs.arizona.edu Maarten v. Casteren (casteren@mpi.nl) wrote: : I was wondering if there is a debugger available for the ICON programming : language. I use the trace-mode sometimes, but find it more easy to print : the value of a variable most of the times. A debugger would solve a lot : of problems and save a lot of time for me. I believe that there was some debugging support in the Icon Programming Library. Is it still there? -- ---------------------- Dave Kuhlman Reify, Redwood City, CA Internet: dkuhlman@netcom.com ---------------------- From icon-group-sender Wed Aug 2 12:02:31 1995 Received: by cheltenham.cs.arizona.edu; Wed, 2 Aug 1995 09:07:45 MST To: icon-group@cs.arizona.edu Date: 02 Aug 1995 12:02:31 GMT From: qbchsod@ebcw131.ericsson (Soderstrom Hakan) Message-Id: Organization: Ericsson Business Networks AB Sender: icon-group-request@cs.arizona.edu References: Subject: Re: ICON debugger? Errors-To: icon-group-errors@cs.arizona.edu Try the 'itweak' package in ftp://cs.arizona.edu/icon/contrib (if it's not in the Icon Program Library). It's quite useful; I know it because I wrote it!-) As you would expect from an interactive debugger it allows you to set breakpoints (possibly conditional), evaluate almost arbitrary expressions, and several other things. Someone may wonder how this is possible. It works by tweaking ucode files (.u1, .u2). This means that after compiling you must run the code through the tweaker. I usually arrange to have two targets in my makefile: one with tweaking/debugging, one without. There has been very scarce feedback about this program. Surprises me, because I find it quite valuable whenever I do serious Icon programming. Hakan Replies/inquiries to hs@soderstrom.se, please. -- ---------------------------------------------------------------------- Hakan Soderstrom (contractor) | qbchsod@ebc.ericsson.se | Memo: EXTR.QBCHSOD Ericsson Business Networks AB | Voice: +46 8 422 0616 NA/EBC/FB/TV | S-13189 Stockholm, SWEDEN | Fax: +46 8 422 0630 From icon-group-sender Wed Aug 2 17:30:28 1995 Received: by cheltenham.cs.arizona.edu; Thu, 3 Aug 1995 08:15:03 MST To: icon-group@cs.arizona.edu Date: 2 Aug 1995 17:30:28 GMT From: Gary Newell Message-Id: <3vocnk$uq9@insosf1.netins.net> Organization: Simpson College Sender: icon-group-request@cs.arizona.edu Subject: save question Errors-To: icon-group-errors@cs.arizona.edu OK OK so I should know this I suppose. But I don't so here goes. We have a couple of DEC Alpha boxes here running OSF (Unix) that act as servers for a number of our courses. Now I have ICON loaded on one of them and all seems well with it. I've used it in a number of courses including Graphics and have not run into any problems yet. Anyway, here's my question. Some students would like to move executables over to the Campus system (the larger Alpha server which does not have ICON installed). So how do they get a true executable? Now I thought that the save() function would do the trick but when I compile it responds as if it has no clue what save(s) is (the usual &null("filename") msg). Is there a reason that this function is not found - did I fail to load something someplace? I'm working on getting them to load ICON on the campus machine but it would be nice to just be able to port an executable over and let students show off some of their work. Thanks. gln From icon-group-sender Thu Aug 3 08:32:45 1995 Received: by cheltenham.cs.arizona.edu; Thu, 3 Aug 1995 12:27:40 MST Date: Thu, 3 Aug 1995 08:32:45 -0700 From: kwalker@sirtur.premenos.com (Ken Walker) Message-Id: <9508031532.AA17612@sirtur.sirtur.premenos.com> To: gln@cs.simpson.edu, icon-group@cs.arizona.edu Subject: Re: save question X-Sun-Charset: US-ASCII Errors-To: icon-group-errors@cs.arizona.edu > Date: 2 Aug 1995 17:30:28 GMT > From: Gary Newell > >... Anyway, here's my question. Some students would like to > move executables over to the Campus system (the larger Alpha server which > does not have ICON installed). So how do they get a true executable? The icon compiler, iconc, will give you a true executable. It's a good idea to re-test the program after compiling as the compiler has more bugs than the interpreter. To run iconc, you need a C compiler on your system, because it uses the C compiler as a back end. Your program will probably run significantly faster after it is compiled, though there are a few programs where it doesn't make much difference. An alternative is to put iconx somewhere on the other system and set the environment variable ICONX to point to its location. You can then execute the output of icont on that system. Ken Walker, kwalker@premenos.com Premenos Coporation, Concord, Ca. 94520 From icon-group-sender Thu Aug 3 09:27:26 1995 Received: by cheltenham.cs.arizona.edu; Thu, 3 Aug 1995 12:27:51 MST Date: Thu, 3 Aug 1995 09:27:26 -0700 From: Gregg Townsend Message-Id: <9508031627.AA13280@hawk.CS.Arizona.EDU> To: gln@cs.simpson.edu, icon-group@cs.arizona.edu Subject: Re: save question Errors-To: icon-group-errors@cs.arizona.edu The save() function only worked on a few systems and is no longer available. You could install your own copy of iconx in your directory on the central server pending an official installation. Your students could then set an ICONX environment variable naming that file, and then their Icon executables would run. The only way to get a true, stand-alone executable is to use the Icon compiler, iconc. That's usually infeasible for programs that use the graphics library due to the size of the library and the time it takes to compile. Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 520 621 4325 gmt@CS.Arizona.EDU 110 57 16 W / 32 13 45 N / +758m From icon-group-sender Thu Aug 3 11:51:20 1995 Received: by cheltenham.cs.arizona.edu; Thu, 3 Aug 1995 12:28:12 MST Date: Thu, 3 Aug 1995 11:51:20 -0500 From: jeffery@runner.jpl.utsa.edu (Clinton L. Jeffery) Message-Id: <9508031651.AA01530@runner.utsa.edu> To: gln@cs.simpson.edu Cc: icon-group@cs.arizona.edu In-Reply-To: <3vocnk$uq9@insosf1.netins.net> (message from Gary Newell on 2 Aug 1995 17:30:28 GMT) Subject: Re: save question Content-Length: 614 Errors-To: icon-group-errors@cs.arizona.edu [Gary Newell wrote asking how to move Icon executables to other machines.] save() was only implemented on a very few, now obsolete operating systems and CPU architectures. Its presence in the red icon book is rather misleading, since it was never available for most platforms. The best way to move executables is to compile them with iconc if you can; otherwise they need to move iconx onto the server, and either setenv ICONX to point to where iconx is installed or else run patchstr on the binaries to point them at the iconx. Clint Jeffery jeffery@ringer.cs.utsa.edu The University of Texas at San Antonio From icon-group-sender Fri Aug 4 09:16:33 1995 Received: by cheltenham.cs.arizona.edu; Fri, 4 Aug 1995 16:21:33 MST Date: Fri, 4 Aug 1995 09:16:33 -0400 From: motto@srd2000.srd.census.gov (Mark Otto) Message-Id: <9508041316.AA21935@srd2000> To: icon-group@cs.arizona.edu Subject: MT Icon Content-Length: 709 Errors-To: icon-group-errors@cs.arizona.edu In issue number 14 of the Analyst, there was an article on Multi-Thread Icon (MT Icon), and at the end of the article it was mentioned that MT Icon could be released to the public at some future date. I thought at the time that MT Icon was the tool someone would need to write an Icon debugger--something that Soderstrom Hakan has done. Now that the Icon group has had more experience with using MT Icon studying dynamic analysis, is it closer to being released or added to the general version of Icon? Mark Otto Census Bureau, Rm 3000-4 (SRD), Washington, DC 20233-9100 Mark.Otto@Census.GOV (at the smtp gateway) or otto@asgard.umd.edu home: 301-431-1838, office: 301-457-4728, fax: 301-457-2299 From icon-group-sender Sat Aug 5 12:27:39 1995 Received: by cheltenham.cs.arizona.edu; Mon, 7 Aug 1995 12:22:46 MST To: icon-group@cs.arizona.edu Date: 5 Aug 95 12:27:39 GMT From: rahardj@cc.umanitoba.ca (Budi Rahardjo) Message-Id: Organization: The University of Manitoba Sender: icon-group-request@cs.arizona.edu Subject: List of icon widgets Errors-To: icon-group-errors@cs.arizona.edu I have just received the Icon newsletter, I am happy that Icon is alive and well. Questions about the graphic facilities (I played with Icon under X a while ago): - Is there a list of available widgets? - How difficult is it to create my own widgets? - I'd like to see widgets that have NeXTstep like look and feel - Would there be an MS-Windows (sic) implementation that can be compiled? -- budi -- Budi Rahardjo #include Unix Support/Administrator - Computer Services - University of Manitoba From icon-group-sender Sun Aug 6 01:44:44 1995 Received: by cheltenham.cs.arizona.edu; Mon, 7 Aug 1995 12:23:03 MST To: icon-group@cs.arizona.edu Date: Sun, 6 Aug 1995 01:44:44 GMT From: cas@netcom.com (Charles A. Shartsis) Message-Id: Organization: NETCOM On-line Communication Services (408 261-4700 guest) Sender: icon-group-request@cs.arizona.edu References: , <3vlhul$bfa@lectura.CS.Arizona.EDU> Subject: Re: ICON debugger? Errors-To: icon-group-errors@cs.arizona.edu Dave Schaumann (dave@CS.Arizona.EDU) wrote: : There's a couple of packages under ftp://cs.arizona.edu/icon/contrib: : debug_tar.Z (also debug.zip) and itweak-2.2.tar.Z (also itweak.lzh). I wrote the DEBUGIFY Icon debugger package (debug_tar.Z/debug.zip) and use it personally to debug my own work. It can be used to set breakpoints, trace or step through a program, display or modify variables. I admit it also has some limitations which I hope to rectify at some future date. It has two parts: 1) the DEBUGIFY program modifies ucode files (.u1 files) and 2) a procedure with the actual debug interface that you link in with yout code. From what I read in another posting, this seems similar to the way itweak sets up debugging. Now that I know of its existence I am interested in trying out itweak and comparing it to DEBUGIFY. : I wrote a gdb-like debugger for Icon using MT Icon that's (IIRC) reasonably : complete. If there's interest, I could make it available. Please do make this debugger available. I am very interested in trying it out. I am assuming it can be used with the University of Arizona Icon, not just MT Icon. By the way, I don't understand why the Icon community has not shown more interest in debugging tools. I consider a good debugger as indispensable and a great time-saver. Its frustrating to try to track down a problem armed only with procedure tracing and write statements. -- Charles A. Shartsis Logicon RDA From icon-group-sender Sat Aug 5 22:31:37 1995 Received: by cheltenham.cs.arizona.edu; Mon, 7 Aug 1995 12:23:19 MST To: icon-group@cs.arizona.edu Date: 5 Aug 1995 22:31:37 -0700 From: dave@cs.arizona.edu (Dave Schaumann) Message-Id: <401k3p$r5u@lectura.CS.Arizona.EDU> Organization: University of Arizona CS Department, Tucson AZ Sender: icon-group-request@cs.arizona.edu References: , <3vlhul$bfa@lectura.CS.Arizona.EDU>, Subject: Re: ICON debugger? Errors-To: icon-group-errors@cs.arizona.edu In article , Charles A. Shartsis wrote: > >: I wrote a gdb-like debugger for Icon using MT Icon that's (IIRC) reasonably >: complete. If there's interest, I could make it available. > >I am assuming it can be used with the University of Arizona Icon, not just >MT Icon. Unfortunately, no -- the unique features of MT Icon are at the very heart of the way my debugger works. Is MT Icon generally available? I looked in the ftp area, and didn't see any sources for it... -Dave From icon-group-sender Mon Aug 7 12:32:03 1995 Received: by cheltenham.cs.arizona.edu; Mon, 7 Aug 1995 16:27:57 MST Date: Mon, 7 Aug 1995 12:32:03 -0700 From: Ralph Griswold Message-Id: <9508071932.AA02963@ursus.cs.arizona.edu> To: dave@cs.arizona.edu, icon-group@cs.arizona.edu Subject: Re: ICON debugger? Errors-To: icon-group-errors@cs.arizona.edu MT-Icon can be built using the standard Icon source code -- it's a matter of conditional compilation. Ralph E. Griswold ralph@cs.arizona.edu Department of Computer Science uunet!arizona!ralph The University of Arizona 520-621-6609 (voice) Tucson, AZ 85721 520-621-4246 (fax) From icon-group-sender Mon Aug 7 16:16:54 1995 Received: by cheltenham.cs.arizona.edu; Mon, 7 Aug 1995 16:28:38 MST Date: Mon, 7 Aug 1995 16:16:54 -0500 From: jeffery@runner.jpl.utsa.edu (Clinton L. Jeffery) Message-Id: <9508072116.AA03265@runner.utsa.edu> To: dave@cs.arizona.edu Cc: icon-group@cs.arizona.edu In-Reply-To: <401k3p$r5u@lectura.CS.Arizona.EDU> (dave@cs.arizona.edu) Subject: Re: ICON debugger? Content-Length: 985 Errors-To: icon-group-errors@cs.arizona.edu From: dave@cs.arizona.edu (Dave Schaumann) >: I wrote a gdb-like debugger for Icon using MT Icon that's (IIRC) >: reasonably complete. If there's interest, I could make it available. >I am assuming it can be used with the University of Arizona Icon, not just >MT Icon. Unfortunately, no -- the unique features of MT Icon are at the very heart of the way my debugger works. Is MT Icon generally available? I looked in the ftp area, and didn't see any sources for it... MT Icon is not a standalone product, it is a set of code that is in Arizona Icon under #ifdef's that are not turned on by default. It has been useful for research but has some rough edges I'd like to polish before I claim it is ready for the general public. Dave, I'd be happy to talk with you about making a set of MT Icon binaries and your debugger available for people to try out on a beta-test basis. Clint Jeffery jeffery@ringer.cs.utsa.edu The University of Texas at San Antonio From icon-group-sender Wed Aug 9 09:58:21 1995 Received: by cheltenham.cs.arizona.edu; Wed, 9 Aug 1995 12:21:18 MST Date: Wed, 9 Aug 1995 09:58:21 -0700 From: Ralph Griswold Message-Id: <9508091658.AA08382@ursus.cs.arizona.edu> To: icon-group Subject: Icon Newsletter Errors-To: icon-group-errors@cs.arizona.edu As announced earlier, the Icon Newsletter now is on the World Wide Web. In case you missed that announcement, it's location is http://www.cs.arizona.edu/icon/www/newsletter/inl.html In addition to the current newsletter, the last three issues are there also. Our plan is to mail out one more free issue of the Newsletter to present subscribers. After that, there will be a subscription charge for paper copies. Information about subscriptions will be contained in that Newsletter. If you are satisfied with getting the Newsletter through the Web, you need do nothing -- your paper subscription will expire automatically if you take no action. Ralph E. Griswold ralph@cs.arizona.edu Department of Computer Science uunet!arizona!ralph The University of Arizona 520-621-6609 (voice) Tucson, AZ 85721 520-621-4246 (fax) From icon-group-sender Wed Aug 9 09:58:21 1995 Received: by cheltenham.cs.arizona.edu; Wed, 9 Aug 1995 12:20:59 MST Date: Wed, 9 Aug 1995 09:58:21 -0700 From: Ralph Griswold Message-Id: <9508091658.AA08382@ursus.cs.arizona.edu> To: icon-group Subject: Icon Newsletter Errors-To: icon-group-errors@cs.arizona.edu As announced earlier, the Icon Newsletter now is on the World Wide Web. In case you missed that announcement, it's location is http://www.cs.arizona.edu/icon/www/newsletter/inl.html In addition to the current newsletter, the last three issues are there also. Our plan is to mail out one more free issue of the Newsletter to present subscribers. After that, there will be a subscription charge for paper copies. Information about subscriptions will be contained in that Newsletter. If you are satisfied with getting the Newsletter through the Web, you need do nothing -- your paper subscription will expire automatically if you take no action. Ralph E. Griswold ralph@cs.arizona.edu Department of Computer Science uunet!arizona!ralph The University of Arizona 520-621-6609 (voice) Tucson, AZ 85721 520-621-4246 (fax) From icon-group-sender Wed Aug 9 10:11:13 1995 Received: by cheltenham.cs.arizona.edu; Wed, 9 Aug 1995 12:21:50 MST Date: Wed, 9 Aug 1995 10:11:13 -0700 From: Ralph Griswold Message-Id: <9508091711.AA08554@ursus.cs.arizona.edu> To: icon-group Subject: Projects from the graphics programming course Errors-To: icon-group-errors@cs.arizona.edu Several persons have inquired about the availability of the student projects from last semester's graphics programming course. It's our intention to make most of the projects available via FTP. Subscribers to the Icon program library update service will get them sooner in the next update, scheduled for later this month. Some projects, however, may not run properly under Version 9.0 of Icon (the latest publicly distributed version), but instead may need Version 9.1. We plan to distribute Version 9.1 this fall. In the meantime we have to test and package the projects. When the projects are available, we'll announce that here. Ralph E. Griswold ralph@cs.arizona.edu Department of Computer Science uunet!arizona!ralph The University of Arizona 520-621-6609 (voice) Tucson, AZ 85721 520-621-4246 (fax) From icon-group-sender Tue Aug 15 11:18:43 1995 Received: by cheltenham.cs.arizona.edu; Tue, 15 Aug 1995 08:36:45 MST Date: Tue, 15 Aug 1995 11:18:43 +0400 (EET-DST) From: "Arne Larsson, NTC, Phone: +358 0 511 27476" To: icon-group@cs.arizona.edu Cc: LARSSON@ntcclu.ntc.nokia.com Message-Id: <950815111843.6020248b@ntcclu.ntc.nokia.com> Subject: Error: XICONXDL cannot run in an OS/2 session Errors-To: icon-group-errors@cs.arizona.edu My first attempt at using the alpha version of ICON 9.0 under OS/2 Warp resulted in error messages to the effect that ICONX and XICONXDL "cannot run in an OS/2 session". Would this be due to incompatibilities between versions of OS/2 or does it have something to do with the resource compiler (my RC.EXE and RCPP.EXE are both dated Feb. 2, 1994). When translating an .icn file, I get the following message from RC: "Writing resources to OS/2 v2.0 Linear .EXE file" Thanks in advance for any help with this problem Best, Arne *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Arne Larsson Nokia Telecommunications CN Co-ordinator Access Systems E-mail: P.O. Box 12, SF-02611 Espoo, Finland Arne.Larsson@ntc.nokia.com Phone +358 0 5117476, Fax +358 0 51044287 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* From icon-group-sender Thu Aug 17 13:26:15 1995 Received: by cheltenham.cs.arizona.edu; Thu, 17 Aug 1995 12:34:02 MST To: icon-group@cs.arizona.edu Date: 17 Aug 1995 13:26:15 GMT From: ruiter@ruls41.fsw.LeidenUniv.nl (Jan-Peter de Ruiter) Message-Id: <40vg1n$q40@highway.LeidenUniv.nl> Organization: Leiden University, The Netherlands Sender: icon-group-request@cs.arizona.edu Subject: Syntax coloring in emacs Icon-mode Errors-To: icon-group-errors@cs.arizona.edu Hi, If there are still people reading this newsgroup, I wonder if there's anyone out there who has implemented syntax coloring for icon mode in emacs. If so, could that someone post it here? Thanks in advance, Jan From icon-group-sender Thu Aug 17 14:08:27 1995 Received: by cheltenham.cs.arizona.edu; Thu, 17 Aug 1995 16:32:59 MST Message-Id: Date: 17 Aug 1995 14:08:27 -0800 From: "Michael Shafto" Subject: lazy question To: icon-group@cs.arizona.edu X-Mailer: Mail*Link SMTP-QM 3.0.2 Errors-To: icon-group-errors@cs.arizona.edu Subject: Time: 14:03 OFFICE MEMO lazy question Date: 8/17/95 For all I know, this exists in the Icon Program Library, but ... I am looking for tools to aid in PL/1 to C source-to-source translation. If a free transloator exists, great! :-) But I'm willing to settle for more limited pattern-matching kinds of things. The project is not that big (24k lines of PL/1), and a useful set of routines for handling the most tedious and repetitious translations (leaving the hard stuff for manual translation) woud be a big asset. Thanks, Mike From icon-group-sender Thu Aug 17 19:21:00 1995 Received: by cheltenham.cs.arizona.edu; Thu, 17 Aug 1995 16:33:14 MST To: icon-group@cs.arizona.edu Date: 17 Aug 1995 19:21:00 GMT From: hs@metis.ele.kth.se (Hakan Soderstrom) Message-Id: Organization: Dept. of Electronics, KTH Sender: icon-group-request@cs.arizona.edu References: Subject: Re: ICON debugger? Errors-To: icon-group-errors@cs.arizona.edu I did not see the original posting from Maarten v. Casteren (casteren@mpi.nl) asking for an Icon debugger. There is a package called 'itweak' in the Icon repository which you may want to try. /cs.arizona.edu:/icon/contrib/ -rw-rw-r-- 1 14 115797 Aug 6 1994 itweak-2.2.tar.Z -rw-rw-r-- 1 14 85506 Aug 16 1994 itweak.lzh The story goes as follows. I was intrigued by the 'debugify' ground-breaking package written by cas@netcom.com (Charles A. Shartsis). However, when debugging sizable programs I found, among other things, that the run-time overhead could be intolerable. After mulling and musing for some time I got a new idea which became 'itweak'. I spent considerable effort on making it a useful tool even in a production environment. I use it myself for any non-trivial Icon programming. The principle is the same as in 'debugify': tweaking the ucode. (You code, I tweak -- that's where 'itweak' comes from.-) The overhead, in space as well in time is radically reduced, as compared to 'debugify'. Not only can you set breakpoints with 'itweak'. You can also evaluate almost any Icon expressions interactively. (Which means that you can inspect the values of local and global variables.) You can build macros for automatic execution at breakpoints. Breakpoints can be conditional. It handles programs built from multiple source files. The 'itweak' debugging system really becomes part of your program. For that reason 'itweak' does not rely on Icon functions to have their usual names. Thus 'itweak' continues to work even if you redefine a function name (for instance: write := 5). I have been astonished by the almost total silence around itweak. I thought a decent interactive debugger would fill an important gap in the Icon programming environment. It's even documented. And there is interactive help for all commands. Try it out and judge for yourself! I'll be glad to hear from you. Hakan -- ---------------------------------------------------------------- Hakan Soderstrom | hs@soderstrom.se Soderstrom Programvaruverkstad AB | Voice: +46 (8) 722 7320 Bandhagsvagen 51 | Fax: +46 (8) 817980 S-122 42 Enskede, SWEDEN | From icon-group-sender Fri Aug 18 16:56:34 1995 Received: by cheltenham.cs.arizona.edu; Fri, 18 Aug 1995 13:07:01 MST To: icon-group@cs.arizona.edu Date: Fri, 18 Aug 1995 16:56:34 GMT From: tydeman@netcom.com (Fred Tydeman) Message-Id: Organization: Tydeman Consulting Sender: icon-group-request@cs.arizona.edu Subject: SNOBOL4 and printing on same line Errors-To: icon-group-errors@cs.arizona.edu The SNOBOL4 Programming Language, second edition ("green book") on page 167-168 talk about output associations and carriage control. In looking at a Fortan manual, if the first character printed on a line is a '1', then a new page eject is done before printing. A '0' causes double spacing, a '+' suppresses spacing before printing, eg, prints two successive records on the same line. Anything else causes a single space before printing. So you need to print a '+' as the first character on a line to print the next record on the same line. In SNOBOL4 do OUTPUT('OUTPUT',6,'(1H+,132A1)') in place of OUTPUT('OUTPUT',6,'(1X,132A1)') -- Fred Tydeman +1 (512) 255-8696 Austin, Texas Computer Consultant tydeman@netcom.com C/C++ Training NCEG/FPCE and numeric Testing Voting Member x3j11 ( ANSI "C" standards committee ) Numerical Editor of the Journal of C Language Translation From icon-group-sender Fri Aug 18 15:23:00 1995 Received: by cheltenham.cs.arizona.edu; Fri, 18 Aug 1995 16:45:17 MST Message-Id: <9508181523.AA21372@ns1.computek.net> Mime-Version: 1.0 Content-Length: 1275 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 18 Aug 95 15:23 CDT From: gep2@computek.net Subject: SNOBOL4 and printing on same line To: icon-group@cs.arizona.edu X-Mailer: SPRY Mail Version: 04.00.06.17 Errors-To: icon-group-errors@cs.arizona.edu >The SNOBOL4 Programming Language, second edition ("green book") on page 167-168 talk about output associations and carriage control. In looking at a Fortan manual, if the first character printed on a line is a '1', then a new page eject is done before printing. ...true, and depending on the version of SNOBOL4 a person is using, this might still be relevant. But the use of the Fortran I/O package was I suspect an expedient in the design of the original SNOBOL4, and is something of an anachronism today. Most of the time, SNOBOL4's own formatting capabilities are much easier to use than Fortran FORMAT statements are. If you're using SNOBOL4+, at least, you can simply output standard ASCII CR and LF control characters as part of your output string, if you wish. To suppress the CR/LF that is automatically added at the end of the output statement, you can include a Ctrl-Z, or CHAR(26), where you wish the output to end. Of course, if you're using a laser printer or something, it may be easier to simply output to the printer in binary mode so you can send the necessary printer positioning/formatting/etc commands directly, allowing you basically infinite flexibility to do whatever you want. Gordon Peterson http://www.computek.net/public/gep2/ From icon-group-sender Fri Aug 18 20:24:29 1995 Received: by cheltenham.cs.arizona.edu; Fri, 18 Aug 1995 16:45:31 MST To: icon-group@cs.arizona.edu Date: 18 Aug 1995 20:24:29 GMT From: soder@ele.kth.se (Hakan Soderstrom) Message-Id: Organization: Dept. of Electronics, KTH Sender: icon-group-request@cs.arizona.edu References: Reply-To: hs@soderstrom.se Subject: Re: itweak ICON debugger, wrong address Errors-To: icon-group-errors@cs.arizona.edu Somehow I managed to get the return address wrong in my posting about the 'itweak' interactive Icon debugger. Sorry for any inconvenience it may have caused. The preferred address for itweak correspondence is hs@soderstrom.se Hakan From icon-group-sender Mon Aug 21 15:25:45 1995 Received: by cheltenham.cs.arizona.edu; Mon, 21 Aug 1995 13:13:47 MST To: icon-group@cs.arizona.edu Date: Mon, 21 Aug 1995 15:25:45 GMT From: mshapiro@nosc.mil (Michael D Shapiro) Message-Id: <1995Aug21.152545.21732@nosc.mil> Organization: NCCOSC RDT&E Division, San Diego, CA Sender: icon-group-request@cs.arizona.edu References: Subject: Re: SNOBOL4 and printing on same line Errors-To: icon-group-errors@cs.arizona.edu In article , Fred Tydeman wrote: > >The SNOBOL4 Programming Language, second edition ("green book") on >page 167-168 talk about output associations and carriage control. >In looking at a Fortan manual, if the first character printed on a >line is a '1', then a new page eject is done before printing. >A '0' causes double spacing, a '+' suppresses spacing before >printing, eg, prints two successive records on the same line. >Anything else causes a single space before printing. > >So you need to print a '+' as the first character on a line to >print the next record on the same line. > >In SNOBOL4 do > OUTPUT('OUTPUT',6,'(1H+,132A1)') >in place of > OUTPUT('OUTPUT',6,'(1X,132A1)') That works _if_ you have a SNOBOL4 implementation that uses (or simulates) the FORTRAN 66 standard for output. We used it because it was the only reasonably portable standard available at the time. Some later implementations of SNOBOL4 use other stream-oriented I/O models (in place of the line-printer-oriented scheme). For some of them, the FORTRAN "carriage control" option does not work. -- Michael D. Shapiro, Ph.D. Internet: mshapiro@nosc.mil Code 4123, NCCOSC RDT&E Division (NRaD) San Diego CA 92152 Voice: (619) 553-4080 FAX: (619) 553-4808 DSN: 553-4080 From icon-group-sender Mon Aug 21 09:48:50 1995 Received: by cheltenham.cs.arizona.edu; Mon, 21 Aug 1995 13:13:38 MST Date: Mon, 21 Aug 1995 09:48:50 -0700 From: Gregg Townsend Message-Id: <9508211648.AA02832@hawk.CS.Arizona.EDU> To: icon-group, rahardj@cc.umanitoba.ca Subject: Re: List of icon widgets Errors-To: icon-group-errors@cs.arizona.edu Date: 5 Aug 95 12:27:39 GMT From: rahardj@cc.umanitoba.ca (Budi Rahardjo) - Is there a list of available widgets? - How difficult is it to create my own widgets? - I'd like to see widgets that have NeXTstep like look and feel - Would there be an MS-Windows (sic) implementation that can be compiled? The vidgets are: buttons, radio buttons, menus, labels, text fields, sliders, scrollbars, rectangular regions, lines Unfortunately, it is not easy to create new vidgets; this requires making changes throughout the vidget library. The forthcoming fall release of the library will include Motif-like 3-D vidgets. We have no plans for alternate looks and feels. A Windows implementation of the Icon interpreter is in the works; no work on the compiler is planned. For graphics programs, especially, it's usually hard to notice a difference in speed. Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 520 621 4325 gmt@CS.Arizona.EDU 110 57 16 W / 32 13 45 N / +758m From icon-group-sender Tue Aug 22 00:58:33 1995 Received: by cheltenham.cs.arizona.edu; Tue, 22 Aug 1995 09:34:59 MST To: icon-group@cs.arizona.edu Date: Tue, 22 Aug 1995 00:58:33 GMT From: jnd@imagen.com (John N. Doyle) Message-Id: <1995Aug22.005833.17315@qms.com> Organization: QMS Inc., Imagen Division Sender: icon-group-request@cs.arizona.edu References: , , Subject: Re: ICON debugger? Errors-To: icon-group-errors@cs.arizona.edu In article hs@metis.ele.kth.se (Hakan Soderstrom) writes: [snip] >I have been astonished by the almost total silence around itweak. I >thought a decent interactive debugger would fill an important gap in >the Icon programming environment. > >It's even documented. And there is interactive help for all commands. > Pearls before swine! It happens to the best of us. :-) JNDoyle From icon-group-sender Wed Aug 23 01:23:39 1995 Received: by cheltenham.cs.arizona.edu; Wed, 23 Aug 1995 06:33:34 MST To: icon-group@cs.arizona.edu Date: 23 Aug 1995 01:23:39 GMT From: btobin@infinet.com (Bruce S. Tobin) Message-Id: <41dvur$hvb@horus.infinet.com> Organization: InfiNet Sender: icon-group-request@cs.arizona.edu Subject: Icon as an editing tool Errors-To: icon-group-errors@cs.arizona.edu I'm looking for a better way to automate (or semi-automate) some heavy C++ editing I'm going to have to do soon, making lots of similar changes to lots of different files. Is this a good use for Icon, or would I be better off with sed, awk, or emacs lisp? Thanks. From icon-group-sender Thu Aug 24 11:02:47 1995 Received: by cheltenham.cs.arizona.edu; Thu, 24 Aug 1995 10:07:36 MST To: icon-group@cs.arizona.edu Date: 24 Aug 1995 11:02:47 +0200 From: janpeter@mpi.nl (Jan Peter de Ruiter) Message-Id: Organization: Max-Panck Institut f|r Psycholinguistik, Nijmegen, the Netherlands Sender: icon-group-request@cs.arizona.edu References: <41dvur$hvb@horus.infinet.com> Subject: Re: Icon as an editing tool Errors-To: icon-group-errors@cs.arizona.edu In article <41dvur$hvb@horus.infinet.com> btobin@infinet.com (Bruce S. Tobin) writes: I'm looking for a better way to automate (or semi-automate) some heavy C++ editing I'm going to have to do soon, making lots of similar changes to lots of different files. Is this a good use for Icon, or would I be better off with sed, awk, or emacs lisp? Thanks. Icon is just fine for this kind of job, but I believe you will save yourself a lot of trouble and time if you take a look at "gema", a text processing macro language that is just made for the kind of jobs you mention. Take a look at it: http://www.ugcs.caltech.edu/gema/. Jan rom icon-group-sender Wed Aug 23 19:04:00 1995 Received: by cheltenham.cs.arizona.edu; Thu, 24 Aug 1995 10:07:25 MST Message-Id: <9508231904.AA15356@ns1.computek.net> Mime-Version: 1.0 Content-Length: 532 Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 23 Aug 95 19:04 CDT From: gep2@computek.net Subject: Icon as an editing tool To: icon-group@cs.arizona.edu X-Mailer: SPRY Mail Version: 04.00.06.17 Errors-To: icon-group-errors@cs.arizona.edu > I'm looking for a better way to automate (or semi-automate) some heavy C++ editing I'm going to have to do soon, making lots of similar changes to lots of different files. Is this a good use for Icon, or would I be better off with sed, awk, or emacs lisp? Thanks. Icon would be (IMHO) --far-- superior for such a task than any of the other alternatives you suggested. (Personally, I think that SNOBOL4 might be even easier still... that's probably what I'd do it in.) Gordon Peterson http://www.computek.net/public/gep2/ From icon-group-sender Thu Aug 24 09:40:09 1995 Received: by cheltenham.cs.arizona.edu; Thu, 24 Aug 1995 12:33:27 MST To: icon-group@cs.arizona.edu Date: 24 Aug 1995 09:40:09 -0700 From: yost@Yost.com (Dave Yost) Message-Id: <41ia19$rj@Yost.com> Organization: Dave Yost's house Sender: icon-group-request@cs.arizona.edu References: <41dvur$hvb@horus.infinet.com>, Subject: Editing multiple files at once Errors-To: icon-group-errors@cs.arizona.edu In article , Jan Peter de Ruiter wrote: >In article <41dvur$hvb@horus.infinet.com> btobin@infinet.com (Bruce S. Tobin) writes: > > I'm looking for a better way to automate (or semi-automate) some heavy > C++ editing I'm going to have to do soon, making lots of similar changes to > lots of different files. Is this a good use for Icon, or would I be > better off with sed, awk, or emacs lisp? Thanks. > >Icon is just fine for this kind of job, but I believe you will save >yourself a lot of trouble and time if you take a look at "gema", a >text processing macro language that is just made for the kind of jobs >you mention. Take a look at it: http://www.ugcs.caltech.edu/gema/. > >Jan One way to do what you want is to catenate all the text files together, edit them with whatever text editor you have handy, then burst the big file back into its constituent files. So happens that the tool I wrote to do this is written in Icon. Enjoy. Dave ======== bundle #!/bin/sh # Author Dave@Yost.com usage() { echo 1>&2 " Usage: bundle file ... Cats a set of text files together for editing. Use unbundle to re-extract them. " exit 2 } case $# in 0) usage esac for x do if test -f $x -a -r $x then echo ' ========' $x cat $x fi done echo ' ========' ======== unbundle.icn # Author Dave@Yost.com procedure main (args) local line local pathname # a/b/c local dirname # a/b local filename # c local tmpname # a/b/c-UNBUNDLE-tmp local file local remove local replace local input local verbose if *args ~= 1 then usage() verbose := 1 if not (input := if match ("-", args[1]) then &input else open (args[1], "r")) then { write (&errout, "Can't open ", args[1]) exit (1) } while line := read(input) do { line ? { if tab(match (" ========")) then { if \file then { close (file) remove := (if \verbose = 2 then "echo 1>&2 " || pathname || " unchanged;" else "") || "rm -f " || tmpname replace := (if \verbose = 1 then "echo 1>&2 " || pathname || ";" else "") || "mv -f " || pathname || " " || backupname (pathname) || "; mv -f " || tmpname || " " || pathname system ("if cmp 2>&1 > /dev/null " || tmpname || " " || pathname || "; then " || remove || "; else " || replace || "; fi") } if move(1) then { pathname := tab(0) filename := filepart (pathname) if dirname := dirpart (pathname) then system ("if test ! -d " || dirname || "; then mkdir -p " || dirname || "; fi") tmpname := pathname || "-UNBUNDLE-tmp" if not (file := open (tmpname, "w")) then { write (&errout, "Can't open temp file \"", tmpname, "\"") exit (1) } } else file := &null } else { write (file, line) } } } if \file then close (file) return end procedure backupname (pathname) return dirpart (pathname) || "/," || filepart (pathname) | "," || pathname end procedure dirpart (pathname) local ind local dirname local filename pathname ? { (every ind := find ("/")) & return tab (ind) } end procedure filepart (pathname) local ind local dirname local filename pathname ? { (every ind := find ("/")) & move (ind + 1) filename := tab (0) } return filename end procedure usage() write (&errout, "\ Usage: unbundle file\ or: unbundle -\ \ Unbundles a file made with the bundle command.\ Each extracted file replaces (rather than overwrites)\ any existing file by that name unless it is unchanged.\ ") exit (2) end ======== From icon-group-sender Tue Aug 29 15:17:04 1995 Received: by cheltenham.cs.arizona.edu; Tue, 29 Aug 1995 12:36:07 MST To: icon-group@cs.arizona.edu Date: 29 Aug 1995 15:17:04 GMT From: acsander@mir.gtri.gatech.edu (Alan Sandercock) Message-Id: <41vb1g$9na@mordred.gatech.edu> Organization: USGS Center for Spatial Analysis Technologies Sender: icon-group-request@cs.arizona.edu Subject: Icon and Linux Errors-To: icon-group-errors@cs.arizona.edu I have recently installed Linux on my P100 with 16 Meg. and since I have run Icon 9 with X extensions on another machine (DG AViiON using DGUX) I am curious about getting Icon up and running on my home machine. I picked up the binary which is on the ftp site in Arizona but it would appear to have a slight problem. Icont runs fine but a compiled Icon program has a reference to a home path id of the author of the compiled Icon source (I presume). I can get around this by executing using Iconx but it is not optimal. Iconc is also giving me problems which are once again being caused by this other person's home pathname being somehow present. Do I need to get the source and compile from scratch? I am also wondering about getting X support up and running, since I am able to run XWindows under Linux and would like to have Icon running in graphics mode. I would especially like to be running Iconc under X and compiling graphics programs. If there is anyone out there who has gone through all of this with Linux and Icon, then I would be interested in hearing from you. Alan Sandercock From icon-group-sender Wed Aug 30 00:04:46 1995 Received: by cheltenham.cs.arizona.edu; Wed, 30 Aug 1995 09:22:24 MST To: icon-group@cs.arizona.edu Date: 30 Aug 1995 00:04:46 GMT From: btobin@infinet.com (Bruce S. Tobin) Message-Id: <4209uu$s1t@horus.infinet.com> Organization: InfiNet Sender: icon-group-request@cs.arizona.edu References: <41vb1g$9na@mordred.gatech.edu> Subject: Re: Icon and Linux Errors-To: icon-group-errors@cs.arizona.edu Alan Sandercock (acsander@csat.gatech.edu) wrote: : I have recently installed Linux on my P100 with 16 Meg. and since I : have run Icon 9 with X extensions on another machine (DG AViiON using : DGUX) I am curious about getting Icon up and running on my home : machine. I picked up the binary which is on the ftp site in Arizona : but it would appear to have a slight problem. Icont runs fine but a : compiled Icon program has a reference to a home path id of the author : of the compiled Icon source (I presume). I can get around this by : executing using Iconx but it is not optimal. Iconc is also Try setting the ICONX environment variable to the pathname (including filename) of your iconx binary. From icon-group-sender Wed Aug 30 00:13:13 1995 Received: by cheltenham.cs.arizona.edu; Wed, 30 Aug 1995 09:22:38 MST To: icon-group@cs.arizona.edu Date: 30 Aug 1995 00:13:13 GMT From: ug301ab@sun3.sunmail.lrz-muenchen.de (Gerhard Brey) Message-Id: Organization: Institut fuer Geschichte der Naturwissenschaften, Munich, Germany Sender: icon-group-request@cs.arizona.edu References: <41vb1g$9na@mordred.gatech.edu> Reply-To: ug301ab@sunmail.lrz-muenchen.de Subject: Re: Icon and Linux Errors-To: icon-group-errors@cs.arizona.edu In article <41vb1g$9na@mordred.gatech.edu> acsander@csat.gatech.edu (Alan Sandercock) writes: > Path: lrz-muenchen.de!informatik.tu-muenchen.de!Germany.EU.net!howland.reston.ans.net!gatech!gt-news!acsander > From: acsander@csat.gatech.edu (Alan Sandercock) > [...] > I picked up the binary which is on the ftp site in Arizona > but it would appear to have a slight problem. Icont runs fine but a > compiled Icon program has a reference to a home path id of the author > of the compiled Icon source (I presume). I can get around this by > executing using Iconx but it is not optimal. Iconc is also > giving me problems which are once again being caused by this other > person's home pathname being somehow present. Do I need to get the source > and compile from scratch? > You will have to patch `icont' and `iconc' to use your paths. A program to do this (`patchstr') is supplied with the binary distribution. A description of how to do this exactly is in one of the README-files which come with the binaries. > I am also wondering about getting X support up and running, since I am > able to run XWindows under Linux and would like to have Icon running > in graphics mode. I would especially like to be running Iconc under X > and compiling graphics programs. > The Linux binaries from ftp.cs.arizona.edu are compiled without X support (the date mark of this distribution was, I think, September 1994), maybe this has changed in the meantime. If not, you will have to get the sources and compile yourself. It compiled without any problems on my machine. Among the documentation files there is a step-by-step guide to compiling Icon, which tells you what to do. > [...] Gerhard -- ............................................................................ Gerhard Brey / Institut fuer Geschichte : ug301ab@sunmail.lrz-muenchen.de der Naturwissenschaften d. Univ. Muenchen : Tel.: +49 89 2180-3252 Postfach / 80306 Muenchen / Germany : FAX: +49 89 2180-3162 From icon-group-sender Wed Aug 30 11:38:36 1995 Received: by cheltenham.cs.arizona.edu; Wed, 30 Aug 1995 09:22:49 MST To: icon-group@cs.arizona.edu Date: Wed, 30 Aug 1995 11:38:36 GMT From: idealord@dorsai.dorsai.org (Jeff Harrington) Message-Id: Organization: The Dorsai Embassy - New York Sender: icon-group-request@cs.arizona.edu References: <41vb1g$9na@mordred.gatech.edu> Subject: Re: Icon and Linux Errors-To: icon-group-errors@cs.arizona.edu Alan Sandercock (acsander@csat.gatech.edu) wrote: : I have recently installed Linux on my P100 with 16 Meg. and since I : have run Icon 9 with X extensions on another machine (DG AViiON using : DGUX) I am curious about getting Icon up and running on my home : machine. I picked up the binary which is on the ftp site in Arizona : but it would appear to have a slight problem. Icont runs fine but a : compiled Icon program has a reference to a home path id of the author : of the compiled Icon source (I presume). I can get around this by : executing using Iconx but it is not optimal. Iconc is also : giving me problems which are once again being caused by this other : person's home pathname being somehow present. Do I need to get the source : and compile from scratch? I installed Linux (and Icon v9) recently and with Clint Jeffery's help (he's the jeffery in the path) re-compiled it for my machine with X-Windows support. It's worth the effort. You must modify the make file in the runtime src directory to point to: XLIB=-L/usr/X11/lib -L/usr/include/X11/ -lX11 instead of what is supplied in the tar file. (At least that's what I remember. If that doesn't work, I can just email you all my make files...). It's a lot of programming bang for the buck when you finally get it running... -- Jeff Harrington idealord@dorsai.dorsai.org -- (*) Most Beautiful Site on the Net: Net in Arcadia http://www.parnasse.com/(*) (*) Elsie Russell's Pics! Jeff Harrington's Music ->>>> Art + The Bizarre (*) (*) Jeff's Musical WWW Site->>>> http://www.parnasse.com/jeff.htm (*) (*) IdEAL ORDER Psychic TV - All Days But Thursdays(ABC) on CBS Since 1984 (*) From icon-group-sender Wed Aug 30 16:56:17 1995 Received: by cheltenham.cs.arizona.edu; Wed, 30 Aug 1995 09:23:03 MST To: icon-group@cs.arizona.edu Date: 30 Aug 1995 16:56:17 +0200 From: janpeter@mpi.nl (Jan Peter de Ruiter) Message-Id: Organization: Max-Panck Institut f|r Psycholinguistik, Nijmegen, the Netherlands Sender: icon-group-request@cs.arizona.edu Subject: icon printing tool Errors-To: icon-group-errors@cs.arizona.edu Hi, Is anyone aware of a program that prints out icon programs in a way similar to tgrind for C or C++2Latex for C++? (you know, bold keywords, italic comments, etc). I've tried to find it in cs.arizona.edu but couldn't find anything. Thanks in advance for any tip, Jan From icon-group-sender Wed Aug 30 12:25:00 1995 Received: by cheltenham.cs.arizona.edu; Wed, 30 Aug 1995 09:57:07 MST Message-Id: <199508301641.MAA09868@transfer.stratus.com> Date: Wed, 30 Aug 95 12:25 EDT From: Steve_Graham@vos.stratus.com To: icon-project@cs.arizona.edu Cc: Steve_Graham@vos.stratus.com Subject: Question Errors-To: icon-group-errors@cs.arizona.edu Dear Sir/Madam: I had originally sent this to icon-info@cs.arizona.edu. However, it was returned due to unknown user. I will try an alternate address. Thanks. --------------------------Original Letter-------------------------------- Dear Sir/Madam: I've read with interest the entries in the comp.lang.icon newgroup and have ordered a copy of Icon. I enjoy the many built-in features which can facilitate many text manipulation tasks. I do have a question about the attached program which I am developing. I am hoping that someone can point out what I am doing wrong. I am sending this via e-mail, inasmuch as I do not have the capability to post to the conference, although I can read posted messages. Perhaps someone could post this to the conference. I am trying to prompt the user to put in a file name. The good news is the program does receive the program name which I type in. The bad news is that I do not see the prompt(s) until after I type in the file name. The problem may be that I do not know how to stipulate to which file (ie, CON) I am writing. Any comments? Thanks in advance. Steve_Graham@vos.stratus.com # # CORRECT .H FILE # # This program fixes the following problems in the t2a*.h file: # # . Eliminates duplicate numbers; # . Corrects the _APS_NEXT_CONTROL_VALUE value; and # . Positions the MF_F and MF_V fields together procedure main() local i,j static numbers initial numbers := "0" every i1 := ( 1 to 9 ) do numbers := numbers || i1 con_file_name := "CON.XXX" write("Calling getfile with ",con_file_name) write("Prompting for source file: ") in_file_name := getfile() write("Calling storelines") storelines(con_file_name,in_file_name,numbers) end procedure getfile(con_file_name) in_file_name := read() return (in_file_name) end procedure storelines(con_file_name,in_file_name,numbers) local i, j, line, linelist, lines, nbr, pair, t, x, y static letters initial letters := &lcase ++ &ucase lines := table(0) t := 0 write("in_file_name(SP): ",in_file_name) in_file_num := open(in_file_name,"ru") while line := read(in_file_num) do { t := t + 1 nbr := 1000 + t nbr := nbr[2:0] lines[nbr] := line } linelist := sort(lines) define_nums := table(0) write("The ",t," lines are: ") every pair := !linelist do { if (i := find("#define",pair[2])) = 1 then { write(pair[1],": ",pair[2]) j := findnumber(pair[2],numbers) k := define_nums[j] + 1 define_nums[j] := k write(" -->",j) if k>1 then write(" *** Duplicate ***") } else write(pair[1],": ",pair[2]) } define_num_list := sort(define_nums) every pair := !define_num_list do write(pair[1],": ",pair[2]) end procedure findnumber(linea,numbers) local i, substr substr := "" linea ? if (i := find(" ",linea))>10 then { i := tab(i) i := tab(upto(numbers)) substr := tab(many(numbers)) } return substr end From icon-group-sender Wed Aug 30 18:01:15 1995 Received: by cheltenham.cs.arizona.edu; Wed, 30 Aug 1995 12:25:44 MST Message-Id: <9508301652.AA25603@eithne.aldiscon.ie> From: Simon Chapman Subject: Re: icon printing tool To: Jan Peter de Ruiter Date: Wed, 30 Aug 1995 18:01:15 +0100 (BST) Cc: icon-group@cs.arizona.edu In-Reply-To: from "Jan Peter de Ruiter" at Aug 30, 95 04:56:17 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1086 Errors-To: icon-group-errors@cs.arizona.edu > Is anyone aware of a program that prints out icon programs in a way > similar to tgrind for C or C++2Latex for C++? (you know, bold > keywords, italic comments, etc). > I have a groff(1) based, configurable source code formatting tool for unix (sed, grep, groff, etc) which I wrote. The whole point of it was to be highly configurable, and does have icon support. Maybe it's fairly basic, and it's probably a good example of what icon does better than standard unix formatting tools, but I'd post it to any interested parties, if it serves as a starting point. It does things like put keywords in bold, comments in smaller point size, and in italics, landscape or portrait, numbers lines. I don't think it would work too well outside of a unix environment. simon -- +-------------------------------------------------+ | Aldiscon Ltd., | simon chapman | | Hambleden House, | simonc@aldiscon.ie | | Lwr. Pembroke St., | Ph.: +353.1.6053183 direct | | Dublin 2, Ireland. | (incl. Voice mail ) | +-------------------------------------------------+ From icon-group-sender Wed Aug 30 12:25:47 1995 Received: by cheltenham.cs.arizona.edu; Wed, 30 Aug 1995 12:25:57 MST Date: Wed, 30 Aug 1995 12:25:47 -0500 From: jeffery@runner.jpl.utsa.edu (Clinton L. Jeffery) Message-Id: <9508301725.AA12714@runner.utsa.edu> To: btobin@infinet.com Cc: icon-group@cs.arizona.edu In-Reply-To: <4209uu$s1t@horus.infinet.com> (btobin@infinet.com) Subject: Re: Icon and Linux Content-Length: 829 Errors-To: icon-group-errors@cs.arizona.edu Try setting the ICONX environment variable to the pathname (including filename) of your iconx binary. This is a correct (and easy) way to run iconx from any location you want to install it. Another alternative is to run the patchstr program to change the icont binary to know where iconx is installed; this is described in the Icon Project Document on UNIX installations. The binaries in the FTP area are old and were done hastily. I'll work on putting up some new Linux binaries built with a newer Linux distribution, and I'll add instructions about the ICONX environment variable in a READ.ME or status file. If someone has some binaries they'd like to contribute for this purpose, you might drop me an e-mail and save me some time. Clint Jeffery jeffery@ringer.cs.utsa.edu The University of Texas at San Antonio From icon-group-sender Tue Sep 5 12:52:00 1995 Received: by cheltenham.cs.arizona.edu; Tue, 5 Sep 1995 16:53:36 MST Message-Id: <199509051703.NAA11013@transfer.stratus.com> Date: Tue, 5 Sep 95 12:52 EDT From: Steve_Graham@vos.stratus.com To: icon-group@cs.arizona.edu Cc: Steve_Graham@vos.stratus.com Subject: Output files in Icon Errors-To: icon-group-errors@cs.arizona.edu I am inexperienced in programming in Icon and I have a question. How does one specify the file/device to which you are trying to output? I figure that it must be something akin to what one does for input: in_file_num := open(in_file_name,"ru") while read(in_file_num) ... But I haven't made the transition yet. Thanks in advance. From icon-group-sender Tue Sep 5 18:12:02 1995 Received: by cheltenham.cs.arizona.edu; Wed, 6 Sep 1995 08:49:59 MST Date: Tue, 05 Sep 95 18:12:02 PST From: "Nielsen, Bill" Encoding: 9 Text Message-Id: <9508058103.AA810354291@cclink.logicon.com> To: icon-group@cs.arizona.edu Return-Receipt-To: bnielsen@cclink-in.logicon.com Subject: HTML/Word Converters Content-Length: 311 Errors-To: icon-group-errors@cs.arizona.edu Is anyone on this list aware of publicly available ICON or SNOBOL4 programs that will convert Microsoft Word 6.0 documents to hypertext markup language (HTML) files and/or convert the other direction. Thank you, Bill Nielsen Logicon, Inc. bnielsen@logicon.com From icon-group-sender Wed Sep 6 02:40:13 1995 Received: by cheltenham.cs.arizona.edu; Wed, 6 Sep 1995 08:51:53 MST To: icon-group@cs.arizona.edu Date: 6 Sep 1995 02:40:13 GMT From: btobin@infinet.com (Bruce S. Tobin) Message-Id: <42j1md$i25@horus.infinet.com> Organization: InfiNet Sender: icon-group-request@cs.arizona.edu Subject: vib? Errors-To: icon-group-errors@cs.arizona.edu I saw some code in one of the demos included with the icon graphics library that was generated (it said) by something called "vib". What is vib? Is it freely available? Do the initials stand for Visual Interface Builder, or what? Just curious. BTW the graphics demos are cool. From icon-group-sender Wed Sep 6 09:21:35 1995 Received: by cheltenham.cs.arizona.edu; Wed, 6 Sep 1995 12:20:34 MST Date: Wed, 6 Sep 1995 09:21:35 -0700 From: Gregg Townsend Message-Id: <9509061621.AA07536@hawk.CS.Arizona.EDU> To: icon-group Subject: Re: vib? Errors-To: icon-group-errors@cs.arizona.edu VIB is indeed a "Visual Interface Builder". It's part of the Icon Program Library, under ...ipl/gpacks/vib. The version used by the class, with a 3-D appearance, will be included in the planned release of Icon 9.1 this fall. The latest documentation can be found as a compressed PostScript file at file://ftp.cs.arizona.edu/icon/doc/ipd265.ps.Z Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 520 621 4325 gmt@CS.Arizona.EDU 110 57 16 W / 32 13 45 N / +758m From icon-group-sender Wed Sep 6 15:13:56 1995 Received: by cheltenham.cs.arizona.edu; Wed, 6 Sep 1995 16:20:32 MST Date: Wed, 6 Sep 1995 15:13:56 -0500 (CDT) From: "Chris D. Tenaglia" To: "Nielsen, Bill" Cc: icon-group@cs.arizona.edu Subject: Re: HTML/Word Converters In-Reply-To: <9508058103.AA810354291@cclink.logicon.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@cs.arizona.edu If you have a valid Word 6.0 license, Microsoft has a freebee called Internet Assistent which overlays Word 6.0a. You then OPEN a word .DOC file and do a SAVE AS *.htm. I downloaded it off the MicroSoft Web page. It's not Icon, but why program if you can SAVE AS? Chris Tenaglia (system manager) | cdt@post.its.mcw.edu Medical College of Wisconsin | 8701 W. Watertown Plank Rd. | Ce que vous voyez est Milwaukee, WI 53226 (414)456-8765 | ce que vous obtenez ! On Tue, 5 Sep 1995, Nielsen, Bill wrote: > Date: Tue, 05 Sep 95 18:12:02 PST > From: Nielsen, Bill > To: icon-group@cs.arizona.edu > Subject: HTML/Word Converters > > Is anyone on this list aware of publicly available ICON or SNOBOL4 > programs that will convert Microsoft Word 6.0 documents to hypertext > markup language (HTML) files and/or convert the other direction. > > Thank you, > > Bill Nielsen > Logicon, Inc. > bnielsen@logicon.com > > From icon-group-sender Thu Sep 7 13:22:42 1995 Received: by cheltenham.cs.arizona.edu; Thu, 7 Sep 1995 16:22:33 MST Date: Thu, 7 Sep 1995 13:22:42 -0700 From: Gregg Townsend Message-Id: <9509072022.AA17488@hawk.CS.Arizona.EDU> To: Steve_Graham@vos.stratus.com, icon-group@cs.arizona.edu Subject: Re: Output files in Icon Errors-To: icon-group-errors@cs.arizona.edu From: Steve_Graham@vos.stratus.com How does one specify the file/device to which you are trying to output? Just pass the file value as an argument to write(). For example: outfile := open(filename, "w") | stop("can't open ", filename) write(outfile, "Here comes the output....") Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 520 621 4325 gmt@CS.Arizona.EDU 110 57 16 W / 32 13 45 N / +758m From icon-group-sender Tue Sep 12 21:53:56 1995 Received: by cheltenham.cs.arizona.edu; Tue, 12 Sep 1995 16:30:16 MST To: icon-group@cs.arizona.edu Date: Tue, 12 Sep 1995 21:53:56 -0500 From: godfroy@ibm.net (Pedro Godfroid Goffin) Message-Id: Sender: icon-group-request@cs.arizona.edu Subject: evaluation stack overflow Errors-To: icon-group-errors@cs.arizona.edu Hi, I do not see too message in this area but anyway as I have an Icon question, I hope someone see it (and know the answer ;-) Well, I get this "evaluation stack overflow" message while running a recursive Icon program (OS/2, 8.1 version). I've tried to fix it changing the MSTKSIZE to greater values but I still got the same error message. Are there any other environment variables that can be changed to try to fix the problem (I have 16 megas of memory and can allocate a bigger OS/2 swapfile if necessary). Bye and thanks, Pedro. From icon-group-sender Tue Sep 12 16:38:29 1995 Received: by cheltenham.cs.arizona.edu; Wed, 13 Sep 1995 09:02:19 MST Date: Tue, 12 Sep 1995 16:38:29 -0700 From: Ralph Griswold Message-Id: <9509122338.AA11677@ursus.cs.arizona.edu> To: godfroy@ibm.net Subject: Re: evaluation stack overflow Cc: icon-group Errors-To: icon-group-errors@cs.arizona.edu If setting MSTKSIZE to a large value doesn't fix the problem, you may just have runaway recursion. It's happened to me when I thought the problem was that the stack size was not large enough. Does the error traceback what you'd expect? Ralph E. Griswold ralph@cs.arizona.edu Department of Computer Science uunet!arizona!ralph The University of Arizona 520-621-6609 (voice) Tucson, AZ 85721 520-621-4246 (fax) From icon-group-sender Tue Sep 12 19:15:04 1995 Received: by cheltenham.cs.arizona.edu; Wed, 13 Sep 1995 09:02:34 MST To: icon-group@cs.arizona.edu Date: 12 Sep 1995 19:15:04 -0700 From: dave@cs.arizona.edu (Dave Schaumann) Message-Id: <435er8$781@lectura.CS.Arizona.EDU> Organization: University of Arizona CS Department, Tucson AZ Sender: icon-group-request@cs.arizona.edu References: Subject: Re: evaluation stack overflow Errors-To: icon-group-errors@cs.arizona.edu In article , Pedro Godfroid Goffin wrote: > > Well, I get this "evaluation stack overflow" message while running >a recursive Icon program (OS/2, 8.1 version). [making the stack >larger doesn't help]] This might be a dumb question, but have you checked to make sure the base case on your recursion is working? -Dave From icon-group-sender Wed Sep 13 09:22:41 1995 Received: by cheltenham.cs.arizona.edu; Wed, 13 Sep 1995 09:02:48 MST Date: Wed, 13 Sep 1995 09:22:41 -0400 From: motto@srd2000.srd.census.gov (Mark Otto) Message-Id: <9509131322.AA10139@srd2000> To: icon-group@cs.arizona.edu Subject: Problem with decode Content-Length: 1822 Errors-To: icon-group-errors@cs.arizona.edu I am using encode and decode (from the IPL) to read and write records of a database with a complicated record structure. These routines are very useful because once I create the structures, I can decode or read them easily and use the records in a number of different programs. Unfortunately when I work with a large number of records (around 800), I get run-time errors. Run-time error 302 File codeobj.icn; Line 220 memory violation Trace back: derecord("10smembershiplcd...","lcdf") from line 167 in codeobj.icn decode("10smembershiplcd...",1) from line 220 in codeobj.icn derecord("7slmemberlcdh29R...","lcdg") from line 167 in codeobj.icn {create ..} from line 220 in codeobj.icn According to the Icon book, error 302 is a stack overflow, but I am getting a memory violation. Is this a problem with the interpreter? I am running on a Sparc 2000 running Solaris 2.3 and Icon Interpreter Version 9.0. July 16, 1994. In Ralph Griswold's codeobj routine, statement 220 is creating a coexpression. 218 procedure detable(s,tag) 219 local t, e 220 e := create decode(s,1) # see derecord above; here it's the default 221 # value that motivates co-expressions. 222 inlab[tag] := t := table(@e) 223 while t[@e] := @e 224 return t 225 end I assume the coexpression stack is overflowing, but changing the COEXPSIZE environmental variable doesn't change the error or where the error occurs. Has anyone else had similiar experiences with these routines? I need help diagnosing this problem. Thanks for your help. Mark Otto e-mail: Mark.Otto@Census.GOV (at the smtp gateway) Census Bureau, Rm 3000-4 (SRD) otto@asgard.umd.edu Washington, DC 20233-9100 office: 301-457-4728 fax: 301-457-2299 home: 301-431-1838 :wq From icon-group-sender Wed Sep 13 09:11:18 1995 Received: by cheltenham.cs.arizona.edu; Wed, 13 Sep 1995 12:29:14 MST Date: Wed, 13 Sep 1995 09:11:18 -0700 From: Ralph Griswold Message-Id: <9509131611.AA17580@ursus.cs.arizona.edu> To: motto@srd2000.srd.census.gov Subject: Re: Problem with decode Cc: icon-group Errors-To: icon-group-errors@cs.arizona.edu Try using xencode() and xdecode() in xcode.icn instead of the procedures in codeobj.icn. xencode() and xdecode() are all-around better. Ralph E. Griswold ralph@cs.arizona.edu Department of Computer Science uunet!arizona!ralph The University of Arizona 520-621-6609 (voice) Tucson, AZ 85721 520-621-4246 (fax) From icon-group-sender Thu Sep 14 11:29:45 1995 Received: by cheltenham.cs.arizona.edu; Thu, 14 Sep 1995 12:21:17 MST Date: Thu, 14 Sep 1995 11:29:45 -0400 From: motto@srd2000.srd.census.gov (Mark Otto) Message-Id: <9509141529.AA16036@srd2000> To: icon-group@cs.arizona.edu Subject: Re: Problem with decode Cc: ralph@cs.arizone.edu X-Sun-Charset: US-ASCII Content-Length: 542 Errors-To: icon-group-errors@cs.arizona.edu I asked for help with a memory violation problem when using the IPL's decode routine. Ralph Griswold gave me the successful suggestion of using xencode and xdecode which are in the new version of the IPL. Now I am able to read in a whole list of records, where the records themselves are records of records (and so on), without any problems. So, everyone using the old encode and decode should try the new x versions in xcode.icn in the IPL. I also have the new version of the IPL to work with. Ralph, thanks for your help. Mark Otto From icon-group-sender Thu Sep 14 11:13:23 1995 Received: by cheltenham.cs.arizona.edu; Fri, 15 Sep 1995 10:11:28 MST To: icon-group@cs.arizona.edu Date: Thu, 14 Sep 1995 11:13:23 GMT From: seldon@eskimo.com (Will Mengarini) Message-Id: Organization: Eskimo North (206) For-Ever Sender: icon-group-request@cs.arizona.edu References: Subject: Re: evaluation stack overflow Errors-To: icon-group-errors@cs.arizona.edu godfroy@ibm.net (Pedro Godfroid Goffin) writes: > Well, I get this "evaluation stack overflow" message while running >a recursive Icon program (OS/2, 8.1 version). I've tried to fix it >changing the MSTKSIZE to greater values but I still got the same >error message. Are there any other environment variables that can >be changed to try to fix the problem (I have 16 megas of memory and >can allocate a bigger OS/2 swapfile if necessary). This kind of thing is almost always caused by infinite recursion, not inadequate memory. Since Icon syntax is subtle, it's quite likely you're infinitely recursing with a construct that would work as you intended in an Algol-family language. I suggest you post the code. From icon-group-sender Fri Sep 15 22:59:21 1995 Received: by cheltenham.cs.arizona.edu; Mon, 18 Sep 1995 11:38:51 MST To: icon-group@cs.arizona.edu Date: 15 Sep 1995 22:59:21 GMT From: carr@fast.cs.utah.edu (Harold Carr) Message-Id: <43d0g9$aal@magus.cs.utah.edu> Organization: CSS Sender: icon-group-request@cs.arizona.edu Subject: what to use instead of TCL or PERL Errors-To: icon-group-errors@cs.arizona.edu What do programmers who implement and use real programming languages like, Lisp, Prolog, Smalltalk, Eiffel, Icon, etc; use instead of TCL or PERL? (sounds like a straight line but I am really asking) Harold From icon-group-sender Fri Sep 15 21:48:30 1995 Received: by cheltenham.cs.arizona.edu; Mon, 18 Sep 1995 11:39:01 MST To: icon-group@cs.arizona.edu Date: Fri, 15 Sep 1995 21:48:30 -0600 From: oakley@healthcare.com (Bryan Oakley) Message-Id: Organization: Healthcare Communications, Inc. Sender: icon-group-request@cs.arizona.edu References: <43d0g9$aal@magus.cs.utah.edu> Subject: Re: what to use instead of TCL or PERL Errors-To: icon-group-errors@cs.arizona.edu In article <43d0g9$aal@magus.cs.utah.edu>, carr@fast.cs.utah.edu (Harold Carr) wrote: > What do programmers who implement and use real programming languages > like, Lisp, Prolog, Smalltalk, Eiffel, Icon, etc; use instead of TCL or PERL? > > (sounds like a straight line but I am really asking) > > Harold Uh, Lisp, Prolog, Smalltalk, Eiffel, and Icon? On a more serious note, what makes you think that users of Lisp, etc. *don't* use TCL or PERL? What exactly do you mean by "use instead of TCL or PERL"? Use for what? Programming? Perhaps they also use the Korn or Bourne shell, python, C, FORTRAN, COBOL, awk, hypercard, and the list goes on and on. -- Bryan Oakley Healthcare Communications, Inc. From icon-group-sender Sat Sep 16 17:17:35 1995 Received: by cheltenham.cs.arizona.edu; Mon, 18 Sep 1995 11:40:08 MST To: icon-group@cs.arizona.edu Date: 16 Sep 1995 17:17:35 GMT From: Bruce Tobin Message-Id: <43f0rf$25o@horus.infinet.com> Organization: Claremont Technology Group Sender: icon-group-request@cs.arizona.edu References: <43d0g9$aal@magus.cs.utah.edu> Subject: Re: what to use instead of TCL or PERL Errors-To: icon-group-errors@cs.arizona.edu Try Python. Also, try Icon itself. Also, gema (a macro processor). From icon-group-sender Sat Sep 16 21:48:19 1995 Received: by cheltenham.cs.arizona.edu; Mon, 18 Sep 1995 11:40:35 MST To: icon-group@cs.arizona.edu Date: 16 Sep 1995 21:48:19 GMT From: ivler@crl.com (J.M. Ivler) Message-Id: <43fgn3$1g4@nntp.crl.com> Organization: CRL Network Services (415) 705-6060 [Login: guest] Sender: icon-group-request@cs.arizona.edu References: <43d0g9$aal@magus.cs.utah.edu> Subject: Re: what to use instead of TCL or PERL Errors-To: icon-group-errors@cs.arizona.edu Harold Carr (carr@fast.cs.utah.edu) wrote: : What do programmers who implement and use real programming languages : like, Lisp, Prolog, Smalltalk, Eiffel, Icon, etc; use instead of TCL or PERL? Harold, all languages are tools. Each has certain strenths and weaknesses. C++ may be good for some applications, not so good for others. The same can be said for all languages. Consider the programmer as a carpenter. He has to sink a screw. Now he could use a hammer to sink it, and it would work, but it would work much better if he used a screwdriver. Additionally, the screw is a philips head. Now he could use a flathead screwdriver, but wouldn't the better tool be a philipshead screwdriver? Now, if he had only one screw to sink, he might use a hand screwdriver, but he has 1000, so might it not be wise to attach a philipshead screwdriver to a powertool to help? At each point in the design of a project the developer looks at the tools in the supply cabinet. He may have to consider porting issues, or issues of GUI interfaces. No matter what the concern, there are always factors that go into determining the "right tool for the job". and that includes the language that the solution should be coded in. I note that you are posting from a .cs.[place].edu I suggest that you may want to look into seeing if they have a class in Intro to Computers that you could take, as the above comes from my notes when I used to teach it. jmi ivler@crl.com set Tcl {a toolbuilders friend} From icon-group-sender Mon Sep 18 10:26:21 1995 Received: by cheltenham.cs.arizona.edu; Mon, 18 Sep 1995 11:41:01 MST To: icon-group@cs.arizona.edu Date: Mon, 18 Sep 1995 10:26:21 GMT From: tgg@hplb.hpl.hp.com () Message-Id: Organization: Hewlett-Packard Laboratories, Bristol, England Sender: icon-group-request@cs.arizona.edu References: <43d0g9$aal@magus.cs.utah.edu>, <43fgn3$1g4@nntp.crl.com> Subject: Re: what to use instead of TCL or PERL Errors-To: icon-group-errors@cs.arizona.edu J.M. Ivler (ivler@crl.com) wrote: |Consider the programmer as a carpenter. He has to sink a screw. Now he could |use a hammer to sink it, and it would work, but it would work much better |if he used a screwdriver. Additionally, the screw is a philips head. Now |he could use a flathead screwdriver, but wouldn't the better tool be a |philipshead screwdriver? Now, if he had only one screw to sink, he might |use a hand screwdriver, but he has 1000, so might it not be wise to |attach a philipshead screwdriver to a powertool to help? Carpenters often _do_ use hammers to insert screws; they hit them in for most of the distance and then screw them in for only the last 1cm or so. Much faster, and it works! Know your tools, and use the appropriate _mix_ of tools! -- =============================================================================== Tom Gardner Hewlett Packard Laboratories, Filton Rd, tgg@hplb.hpl.hp.com Stoke Gifford, Bristol, Avon, BS12 6QZ, ENGLAND. Fax: +44 1179 228920 Tel: +44 1179 799910 ext. 28192 Too many Heritage Centres make you go blind. =============================================================================== From icon-group-sender Mon Sep 18 16:24:15 1995 Received: by cheltenham.cs.arizona.edu; Mon, 18 Sep 1995 12:39:56 MST To: icon-group@cs.arizona.edu Date: 18 Sep 1995 16:24:15 GMT From: ggraham@crchha98.bnr.ca (Gregory Graha) Message-Id: Organization: Bell Northern Research, Richardson, TX. Sender: icon-group-request@cs.arizona.edu References: <43d0g9$aal@magus.cs.utah.edu>, Subject: Re: what to use instead of TCL or PERL Errors-To: icon-group-errors@cs.arizona.edu In article oakley@healthcare.com (Bryan Oakley) writes: In article <43d0g9$aal@magus.cs.utah.edu>, carr@fast.cs.utah.edu (Harold Carr) wrote: > What do programmers who implement and use real programming languages > like, Lisp, Prolog, Smalltalk, Eiffel, Icon, etc; use instead of TCL or > PERL? > > (sounds like a straight line but I am really asking) > > Harold Uh, Lisp, Prolog, Smalltalk, Eiffel, and Icon? On a more serious note, what makes you think that users of Lisp, etc. *don't* use TCL or PERL? What exactly do you mean by "use instead of TCL or PERL"? Use for what? Programming? Perhaps they also use the Korn or Bourne shell, python, C, FORTRAN, COBOL, awk, hypercard, and the list goes on and on. A valid issue to discuss, however, has to do with the fact that Tcl and Perl were pretty much designed to enhance the C/Unix programming environment. Their existance is a testement to the fact that C was considered not suitable for the tasks Tcl and Perl were invented for. Tcl was designed to provide a way to imbed a scripting language into a tool so that the tool could be customized by the user without digging into the C code and recompiling. Although I am new to Smalltalk, the impression I get is that tools in a Smalltalk environment are customized in Smalltalk. The browser makes it easier to deal with the source, and subclassing makes it easier to reuse and customize. Also, the interactive nature of Smalltalk is similar to Tcl. Perl was designed to provide a lot of the high level tools that C lacks, and to provide an interactive programming environment that is more productive for quick jobs than compiled C. Again, these are areas where Smalltalk already excels, with its rich class library and interactive programming environment. Now, I will admit that Tcl and Perl, have definately grown beyond their original vision, and people are using them for all kinds of things. Also, I know that Smalltalk is not the end-all, and there will be cases where a Smalltalk programmer might want to use something like Tcl or Perl. But in general, I think a Smalltalk programmer would have less need for these kinds of tools than a C/C++ programmer. -- Greg Graham ggraham@bnr.ca From icon-group-sender Mon Sep 18 16:22:52 1995 Received: by cheltenham.cs.arizona.edu; Mon, 18 Sep 1995 16:23:02 MST Date: Mon, 18 Sep 1995 16:22:52 -0400 (EDT) From: "Phillip L. Thomas" To: Harold Carr Cc: icon-group@cs.arizona.edu Subject: Re: what to use instead of TCL or PERL In-Reply-To: <43d0g9$aal@magus.cs.utah.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Errors-To: icon-group-errors@cs.arizona.edu I "really" use SNOBOL (SPITBOL, actually) then icon then C. What I use depends on what the problem is: Examples: pattern matching: SNOBOL4/SPITBOL Telephone directories, converting GPO codes to HTML, creating on-line dictionaries for Fox language project. list processing: icon Searching for duplicates in Congressional bills database, reformatting telephone control data- bases. using database libraries: C Customizing U. Mass.'s Inquery database indexing and retrieval engines. -- Phillip Thomas Library of Congress On 15 Sep 1995, Harold Carr wrote: > > > What do programmers who implement and use real programming languages > like, Lisp, Prolog, Smalltalk, Eiffel, Icon, etc; use instead of TCL or PERL? > > (sounds like a straight line but I am really asking) > > Harold > > >