UWC6NTG@UICVMC.BITNET (Nicholas Geovanis 312-996-0590) (07/27/89)
Bob Loewenstein mentioned NEON, which I read an article on a few years back,
but filed and forgot about. Can anyone point me to a comprehensive source
describing syntax and philosophy? How about commercial and PD interpreters?
Much Obliged,
Nick Geovanis - UWC6NTG at UICVMC.EDU
SysProg - Univ. of Ill. Admin. Comp. Ctr.
Chicagorfl@oddjob.uchicago.edu (Bob Loewenstein) (07/28/89)
Kriya is no longer supporting Neon, as far as I know. But we at U of C are, having been involved with Chuck Duff and its development. Kriya updated Neon up to version 2.0 which supported HFS, floating point, and assembly; in addition, most of the bugs were fixed. Since then we have created interfaces to color quickdraw and have developed image processing software on a Mac II. The original 2.0 works on a MacII and SE030, and under multifinder; I think this is testimony to Chuck and the others that created this environment when 512 macs were just becoming widespread (prior to Mac+'s). Even though Kriya no longer supports it, it is easy to massage it to keep current on newer macs and ROMS. It's simple to write interfaces to new calls in the toolkit of the Mac. I look at Neon as a great enhancement to Forth. Forths have a tradition of being supported by its users, and Neon is not unique in this. kevinbe@microsoft.UUCP (Kevin Berg) writes: > It might also be interesting for you to share some of the OO implementations > that you find useful, or cumbersome, via example. I'm sure many others > would be interested. One example is color image support on a Mac II. If anyone has tried this after reading the sections in IM V5, you know what I mean. A lot of things need to be done for each image and window that is created. By making an image class and a colorWindow class, with the appropriate pixmaps and colortables as instance variables created when needed, the whole operations becomes quite easy. Multiple images are just multiple instances of the same class, which can be targeted to any colorWindow object. I don't have to write specialized code for each image, nor do I have to worry about creating the windowPalette, the colorTable, etc. each time I create another image. In fact, it works so nicely, I really have forgotton how things work since it's now part of my system. I don't have to handle button hits, menu hits, event queues...they are all handled by the Neon system. It's relatively simply to affect global changes deep in the system by small inheritances later on. Nicholas Geovanis writes: > but filed and forgot about. Can anyone point me to a comprehensive source > describing syntax and philosophy? How about commercial and PD interpreters? Kurt Schmucker's book on object oriented languages and the Mac had a section on Neon. It was prior to version 2.0. As I remember, he rated it the fastest of all the implementations. This is partly due to the fact that early binding is the default, with an option to late bind if one wants. We have thought of porting Neon to other machines. It doesn't seem to be that difficult, just requiring some time to do the work. Most of the code is at high level. If anyone is interested, they could write me directly, or call. Bob Loewenstein Dept. of Astronomy and Astrophysics University of Chicago Williams Bay, Wi 53191 414-245-5555
heins@hpdml93.HP.COM (Doug Heins) (08/01/89)
/ hpdml93:comp.lang.forth / rfl@oddjob.uchicago.edu (Bob Loewenstein) / 9:32 am Jul 28, 1989 / Kriya is no longer supporting Neon, as far as I know. But we at U of C are, having been involved with Chuck Duff and its development. Kriya updated Neon up to version 2.0 which supported HFS, floating point, and assembly; in addition, most of the bugs were fixed. Since then we have created interfaces to color quickdraw and have developed image processing software on a Mac II. The original 2.0 works on a MacII and SE030, and under multifinder; I think this is testimony to Chuck and the others that created this environment when 512 macs were just becoming widespread (prior to Mac+'s). Even though Kriya no longer supports it, it is easy to massage it to keep current on newer macs and ROMS. It's simple to write interfaces to new calls in the toolkit of the Mac. I look at Neon as a great enhancement to Forth. Forths have a tradition of being supported by its users, and Neon is not unique in this. kevinbe@microsoft.UUCP (Kevin Berg) writes: > It might also be interesting for you to share some of the OO implementations > that you find useful, or cumbersome, via example. I'm sure many others > would be interested. One example is color image support on a Mac II. If anyone has tried this after reading the sections in IM V5, you know what I mean. A lot of things need to be done for each image and window that is created. By making an image class and a colorWindow class, with the appropriate pixmaps and colortables as instance variables created when needed, the whole operations becomes quite easy. Multiple images are just multiple instances of the same class, which can be targeted to any colorWindow object. I don't have to write specialized code for each image, nor do I have to worry about creating the windowPalette, the colorTable, etc. each time I create another image. In fact, it works so nicely, I really have forgotton how things work since it's now part of my system. I don't have to handle button hits, menu hits, event queues...they are all handled by the Neon system. It's relatively simply to affect global changes deep in the system by small inheritances later on. Nicholas Geovanis writes: > but filed and forgot about. Can anyone point me to a comprehensive source > describing syntax and philosophy? How about commercial and PD interpreters? Kurt Schmucker's book on object oriented languages and the Mac had a section on Neon. It was prior to version 2.0. As I remember, he rated it the fastest of all the implementations. This is partly due to the fact that early binding is the default, with an option to late bind if one wants. We have thought of porting Neon to other machines. It doesn't seem to be that difficult, just requiring some time to do the work. Most of the code is at high level. If anyone is interested, they could write me directly, or call. Bob Loewenstein Dept. of Astronomy and Astrophysics University of Chicago Williams Bay, Wi 53191 414-245-5555 ----------
rfl@oddjob.uchicago.edu (Bob Loewenstein) (10/08/90)
I have been negotiating with Kriya (which is located in the DC area) about getting NEON into the public domain. As of last week, they agreed to send me a letter allowing the NEON sources to be shared. However, the stipulation was that all references to the word 'NEON' be left out, since there is some legal problem about the use of that name. I have not received the letter yet, but when I do, I will arrange to release the sources as has been maintained to the present.. The current version of NEON that we use is up to 3.2, maintained by a few of us at University of Chicago. Because it runs on a macintosh, and we have not ported it to another machine (although that wouldn't be too difficult), major differences from Kriya's last released version 2.0 are: multifinder compatible, support for color quickdraw, works on all macs from mac+ to iici (not tested on an fx). While it supports all toolbox calls, not all the interfaces have been written. The sources I'll release include memory, event, window, control, strings, serial i/o, utilities, device, floating point, and many other manager interfaces. We also have TeEdit, Color Quickdraw, MacTCP, and other interfaces as well, but these would be available separately, since they were developed for applications, and not as generic interfaces. While bugs may exist, I am aware of none in the 3.2 system. In a related note, MOPS, Michael Hore's version of NEON will also be available in the public domain. He took the nucleus and rewrote it as threaded subroutine calls. He also changed all memory management to use relocatables for less heap fragmentation. It runs faster that NEON, but doesn't yet support floating point. Many neon sources will compile into MOPS, but not all. He also has a simple implementation of multiple inheritence. Since we have a large number of NEON applications to support, we will probably continue to use NEON rather than MOPS. On most macII type machines, NEON runs fast, so that speed is not an issue. Number crunching is best done in other languages, better designed for algebraic formulation. I'll post another note when I receive the letter from Kriya, but this negotiation has been going on for almost a year. I talked to Chuck Duff a few months ago, and he has helped by writing a letter to Kriya to encourage them to release NEON into the public domain. Anyone interested can contact me at Bob Loewenstein Dept. of Astronomy and Astrophysics The University of Chicago Yerkes Observatory Williams Bay, Wi 53191 rfl@oddjob.uchicago.edu 414-245-5555
loeffler@phoenix.aca.mcc.com (David D. Loeffler) (11/14/90)
Sorry to bring this up again but I missed about a month or two of forth news. What is the current status of Neon? I got this for my Mac may moons ago and have heard talk that it may be put into the public domain. Is this true? If not, is there any group that is going to take over support?
loeffler@phoenix.aca.mcc.com (David D. Loeffler) (11/14/90)
Sorry to bring this up again but I missed about a month or two of forth news. What is the current status of Neon? I got this for my Mac many moons ago and have heard talk that it may be put into the public domain. Is this true? If not, is there any group that is going to take over support?
rfl@oddjob.uchicago.edu (Bob Loewenstein) (11/14/90)
I'm still trying to squeeze the letter from Kriya (Neon's owner) that will give me the authority to release it to the public domain. I've had verbal assurances that this will happen, but it takes these guys a while to put anything into writing. As soon as I get something in writing, I'll post a note to this news group telling where Neon for the Mac will be available. Again, for those that don't know, Neon is an object oriented language based on forth. We have maintained it at UofC and it runs under all systems >4.2 and on all macs >512k. It was a product several years ago, but is no longer.
rfl@oddjob.uchicago.edu (Bob Loewenstein) (01/18/91)
After a long negotiation period with Kriya Systems, I have received written permission to release Neon into the public domain. The letter from Kriya reads: "Kriya Systems, Inc. gives you [me] the permission to freely distribute for scientific and educational purposes the programming language formerly known as Neon, including the distribution of the source which has been released to you. You do not have the right to use the name Neon, as it apparently had prior use by another company and is not a valid trademark of Kriya Systems. All commercial distribution rights are reserved by Kriya Systems, Inc." Since a few of us at the University of Chicago have modified the language somewhat, and to comply with Kriya's wishes, we have renamed the language Yerk, which is at least not an acronym for anything, but rather stands for Yerkes Observatory, part of the Department of Astronomy and Astrophysics at U of C. For those who don't know about Neon, it was an object oriented, macintosh targeted language based on a Forth Kernel with some major modifications. It was developed and sold as a product by Kriya Systems from 1985 to 1988. Because it is an extensible language, it was possible for us to keep it compatible with new toolkit calls, new mac managers, etc. We have modified the nucleus to make improvements, but it is still an evolving language. We are releasing it at this time because it is a very useable and powerful language/environment for the mac. We have written many data acquisition and display programs with Yerk, as well as graphical interfaces for instrument control (both telescopes and instruments). While not part of this release, we have written interfaces for color quickdraw for image processing programs, and a MacTCP interface for network interface. These and other interfaces will probably be made available on request, with the understanding that they were written for specific applications and not as general support interfaces. Some features of the language are: - defaulted early binding, with ability to late bind in almost any circumstance - inheritance (not multiple) - floating point (SANE) - many system classes and objects for mac interfacing: windows, controls, events, files, arrays, ordered-columns, menus, hierarchical and popup menus, handles, strings, mouse, quickdraw, modal dialogs, offscreen bitmaps, vbl, time manager, etc. - module (overlay) creation that are loaded only when necessary and may be purged from application heap memory. Some forth extensions are: - local input parameters - named input variables - multiple cfa words (including vectors and values) - CASE - SELECT - 68000 assembler We have used the language on the following macs: mac+,se,se30,macII,IIci,IIx,IIcx. There is no reason to believe that it won't work on any mac+ or beyond. Any system >= 6.0 is recommended. The complete source files, an executable Yerk environment, and update manual (MS Word 4.0 format) are available with anonymous ftp at oddjob.uchicago.edu in ~ftp/pub/Yerk directory. They are compressed with Stuffit and then binhexed. Please try to download these files in the evening hours. In the near future, these files may be added to the MacTutor source code disk. If anyone has any questions, feel free to contact me: Bob Loewenstein Yerkes Observatory Williams Bay, Wi 53191 414-245-5555 rfl@oddjob.uchicago.edu